MDADM+EXT4 таки уделывает ZFS

И где там у вас снапшоты?

скоро будут треды уровня «что выбрать для снапшотов в ZFS» и главное, чтобы такими, присущими линупсу темпами генерирования ненужно, не возникло тредов OpenZFS vs GNUZFS vs LibreZFS?

1. zfs-auto-snapshot — ZFS automatic snapshot service
2. zfsnap — Automatic snapshot creation and removal for ZFS
3. simplesnap — Simple and powerful network transmission of ZFS snapshots

хотя, GNUZFS можно ждать не раньше 2045

пофиг кто там раньше кто позже, мы говорим о текущем положении.

Так что там со снапшотами, где они применяются реально? Можно ли откатить состояние системы после неудачного обновления ПО или приходится заново переустанавливать систему из заранее сохранённого образа? Есть такая практика в линуксах или ещё нет?

Что там с потерянными файлами в случае какого-то сбоя, система может отрапортовать, какие файлы повреждены или свалит в одну кучу /.lost+found ошмётки под незначащими именами - разбирайся в этой куче сам?

Ты хочешь чтобы я тебя учил линуксу?

Ну поучи - послушаю.

Для mdadm+ext4 были выбраны опции --buffered=0 --direct=1. ZFS не умеет работать с этими опциями, поэтому ожидается, что результат ZFS будет несколько выше.

кокой-то дурачок писал, дальше можно не читать, выводы он забавные делает.

Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций.

он даже не понимает, что за дичь несёт и что меряет он сферических коней. далее, он тестирует 4к блоками на 128к файловой системе, и не понимает этого - ну, что тут ещё сказать - сказочный долбоклюй.

На LVM они тормозные, а из классических ФС поддерживают снапшоты только UFS2 и XFS.

А чем маслофс не угодила?

позор - это быть таким безграмотным дебилом, как автор статьи, там в каментах правильно его гнобят.

Не в равной мере. Автор - всего один из обывателей хабра, а ZFS - широкоиспользуемая ФС, именам разработчиков которой многие доверяют

многие как раз и доверятся такому вот обывателю, а что, он же типа риально её использует(уж лучше бы улицы подметал). но главная проблема не в этом, а втом, что по-умолчанию у zfs размер блока равен 128k, 128к/4к = в 32 раза больше работы с диском, ему на это указали неоднократно, так он всё равно не понял ничего.

ZFS - широкоиспользуемая ФС, именам разработчиков которой многие доверяют

разработкам какой из трёх ZFS ты доверяешь?

Ну например Sun, царство ей небесное, я доверял очень даже. И бизнес все же доверяет Oracle

Хочешь учиться — или учись сам или плати.

ZFS хватит всем. Классическим ФС и нагромождениям из «матрёшек» (md-adm, LVM) место на свалке истории.

Ага, вин-реестра хватит всем, классическим plain-text конфигам место на свалке истории.

Изя, я думал ты вылечился от zfs-зависимости переходом на java.

С переходом на FreeBSD (2006г) и нативную ZFS (2009г) я вылечился от бессмысленной траты времени на бесперспективные технологии.

FreeBSD
бесперспективные технологии
я вылечился

made my day.

Вот ни разу не заходил в этот lost+found, хотя файлы повреждались. Спасибо, что напомнил.

Значит, тебе не важны файлы, которые ты держишь на классических ФС.

Кстати, как ты определяешь, что файлы повреждены?

А как ты определяешь, что файлы повреждены? Вот был тут на ЛОРе случай с поврежденными файлами на zfs и zfs этого не заметила. Ты в пролете!

Ага, вин-реестра хватит всем, классическим plain-text конфигам место на свалке истории.

Почему-то стараются «продублировать» всё, что наредактировали в текстовом конфиге (/usr/sbin/pwd_mkdb -p /etc/master.passwd; cap_mkdb /etc/login.conf), а не заниматься разбором текстовой белиберды.

Надеюсь, администраторы прочли главу о сбоях и восстановлении ZFS Руководства по администрированию этой ФС. Всё остальное бессмысленно.

Определяет их ФС, а я пользуюсь.

и zfs этого не заметила.

я понимаю что зфс-фанбоям не надо напрягаться и вчитываться в смысл, но тогда и остальным на тебя пох

Напрягаться надо тому, кто делает заявления («Вот был тут на ЛОРе случай с поврежденными файлами на zfs и zfs этого не заметила»), не подтверждённые ссылками и цитатами.

Это в ответ на твои неподтвержденные заявления о зфс, которая все порчи файлов сразу видит и сообщает.

Пруфы ищи в темах DALDON

Не нашёл.

www.linux.org.ru/search.jsp?q=zfs побились файлы&range=ALL&interval=A...

ты вообще осознаёшь, что линк на тред почти трёхлетней давности с проблемами OpenZFS — это зфс-хейтерство и тупняк?
кто вообще в этом треде OpenZFS использует?
я тестирую OpenZFS и для меня оно говно.
да, работает, но это как машина времени в 2010. и это на секундочку, почти в 2018, а ты тут покрытые мхом «пруфы» приносишь.
чтобы доказать «что»? что ты хейтер ни разу не использующий эту штуку, но срёшь её, просто потому, что любая новизна для хейтера это «зло и ненужно»?
читаю этот тред и ничего кроме стандартного лоровского хейтерства. ни один человек, который попадёт в этот тред случайно не получит никакой информации. просто безинформативный мусор благодаря таким хейтерам.
пять хейтерств из пяти в этом посте.

Ты неадекват и фанбой — проверенно предыдущими общениями.

Дискутировать с фанатами бессмысленно. Продолжай бомбить.

zol , не всё так хорошо...
начал читать это тред.
OpenZFS на непонятно как настроенном raid контроллере с битой памятью.
ппц, не могу отрицать, что я неадекват, но за такие линки как пруфы херовости ZFS нужно лишать скора.

На линуксе всегда были проблемы с дисковой подсистемой, когда шла адская нагрузка I/O. «Всё виснет, работать невозможно» - это ещё мягко сказано. При обычной компиляции мышь дёргается - приходится выставлять понижающие приоритеты на make и сс, чего сроду не замечено на FreeBSD.

Ты скачешь по темам как бешеная блоха. К потере файлов 12309 отношения не имеет.

Заява за zfs как за систему предупреждающей о порче файлов и вообще — оказалась несостоятельной. Плохие диски, плохая память — это такая же проблема как и отключение питания, которого тоже никогда не должно быть при хорошей электросети и УПС.

Так что либо кончайте со своей пропагандой зфс как серебряной пули или кончайте ныть и отвечайте за ее неустойчивость против глючного железа.

Заява за zfs как за систему предупреждающей о порче файлов и вообще — оказалась несостоятельной.

линк на заяву, где сказано, что дырявая память и дохлые диски не помеха zfs сохранять файлы в целости. или иди в жопу.

Заява за zfs как за систему предупреждающей о порче файлов и вообще — оказалась несостоятельной.

Разуй глаза на проблему в самой теме:

root@kvm2:~# zpool status -v

...

errors: Permanent errors have been detected in the following files:

        /zroot/kvm1/copy500/copy500.qcow2
        /zroot/kvm2/prd2/prd2.qcow2

отвечайте за ее неустойчивость против глючного железа.

ZFS в отличие от классических ФС, борется за свою жевучесть и живучесть файлов пользователя на любом железе. Единичные ошибки чтения устраняются БЕЗ вмешательства пользователя. Неустранимые ошибки блокируют доступ к повреждённым файлам - их список можно прочитать в статусе пула. Всё.

Есть под рукой ссылка на методы восстановления таких файлов? Ну, т.е. как правильно. Причем, несколько вариантов, типа а) заменить из бекапа б) разблокировать и считать остатки

Ты сам дискредитируешь критиков ZFS, давая такие ссылки, и, вероятно, являешься латентным zfs фаном.

Я скептически отношусь к ZFS в рамках проекта ZOL и являюсь сторонником классики mdadm+lvm+ext4 на linux. Потому что считаю ZFS On Linux монстром.

Но как раз ситуация у DALDON-a понятна и адекватна - и никаких претензий к ZFS в том случае быть не может. С ext4 мы бы тоже получили битый файл образа, из-за того же сбоя памяти, но не узнали бы об этом на том же уровне.

Неустранимые ошибки с повреждёнными файлами на ZFS устраняются единственно верным способом - восстановлением из бэкапа. Все остальные способы, предлагаемые нам классическими ФС с помощью утилит fsck и file recovery относятся к недостоверным методам и сродни шаманизму на байтовом уровне (для ZFS существует zdb - отладчик ФС, который работает на таком же уровне, но более тонко).

Ок, из бекапа. А конкретней, что надо написать, что бы ZFS отпустило занятое поврежденным файлом место, не знаешь?

Сброс ошибок устройств в пуле устройств хранения данных.

дохлые диски как раз не проблема, а от битой не ecc памяти, да, не спасёт ничто.

при помощи zdb можно собрать поломанный пул и вычитать инфу пропуская битые адреса, другой вопрос, что ты получишь на выходе.

Я правильно понимаю, что после этой операции те файлы с ошибками удалятся? Или их станет возможно удалить командой «rm» ? Если второе, то возможно ли будет вместо rm вычитать их, например, dd, пусть и с ошибками внутри?

при помощи zdb

спасибо, буду иметь ввиду