скоро будут треды уровня «что выбрать для снапшотов в ZFS» и главное, чтобы такими, присущими линупсу темпами генерирования ненужно, не возникло тредов OpenZFS vs GNUZFS vs LibreZFS?
zfs-auto-snapshot — ZFS automatic snapshot service
zfsnap — Automatic snapshot creation and removal for ZFS
simplesnap — Simple and powerful network transmission of ZFS snapshots
Так что там со снапшотами, где они применяются реально? Можно ли откатить состояние системы после неудачного обновления ПО или приходится заново переустанавливать систему из заранее сохранённого образа? Есть такая практика в линуксах или ещё нет?
Что там с потерянными файлами в случае какого-то сбоя, система может отрапортовать, какие файлы повреждены или свалит в одну кучу /.lost+found ошмётки под незначащими именами - разбирайся в этой куче сам?
Для mdadm+ext4 были выбраны опции --buffered=0 --direct=1. ZFS не умеет работать с этими опциями, поэтому ожидается, что результат ZFS будет несколько выше.
кокой-то дурачок писал, дальше можно не читать, выводы он забавные делает.
Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций.
он даже не понимает, что за дичь несёт и что меряет он сферических коней.
далее, он тестирует 4к блоками на 128к файловой системе, и не понимает этого - ну, что тут ещё сказать - сказочный долбоклюй.
многие как раз и доверятся такому вот обывателю, а что, он же типа риально её использует(уж лучше бы улицы подметал).
но главная проблема не в этом, а втом, что по-умолчанию у zfs размер блока равен 128k, 128к/4к = в 32 раза больше работы с диском, ему на это указали неоднократно, так он всё равно не понял ничего.
Ага, вин-реестра хватит всем, классическим plain-text конфигам место на свалке истории.
Почему-то стараются «продублировать» всё, что наредактировали в текстовом конфиге (/usr/sbin/pwd_mkdb -p /etc/master.passwd; cap_mkdb /etc/login.conf), а не заниматься разбором текстовой белиберды.
Напрягаться надо тому, кто делает заявления («Вот был тут на ЛОРе случай с поврежденными файлами на zfs и zfs этого не заметила»), не подтверждённые ссылками и цитатами.
ты вообще осознаёшь, что линк на тред почти трёхлетней давности с проблемами OpenZFS — это зфс-хейтерство и тупняк?
кто вообще в этом треде OpenZFS использует?
я тестирую OpenZFS и для меня оно говно.
да, работает, но это как машина времени в 2010. и это на секундочку, почти в 2018, а ты тут покрытые мхом «пруфы» приносишь.
чтобы доказать «что»? что ты хейтер ни разу не использующий эту штуку, но срёшь её, просто потому, что любая новизна для хейтера это «зло и ненужно»?
читаю этот тред и ничего кроме стандартного лоровского хейтерства. ни один человек, который попадёт в этот тред случайно не получит никакой информации. просто безинформативный мусор благодаря таким хейтерам.
пять хейтерств из пяти в этом посте.
zol , не всё так хорошо...
начал читать это тред.
OpenZFS на непонятно как настроенном raid контроллере с битой памятью.
ппц, не могу отрицать, что я неадекват, но за такие линки как пруфы херовости ZFS нужно лишать скора.
На линуксе всегда были проблемы с дисковой подсистемой, когда шла адская нагрузка I/O. «Всё виснет, работать невозможно» - это ещё мягко сказано. При обычной компиляции мышь дёргается - приходится выставлять понижающие приоритеты на make и сс, чего сроду не замечено на FreeBSD.
Заява за 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 - отладчик ФС, который работает на таком же уровне, но более тонко).
Я правильно понимаю, что после этой операции те файлы с ошибками удалятся? Или их станет возможно удалить командой «rm» ? Если второе, то возможно ли будет вместо rm вычитать их, например, dd, пусть и с ошибками внутри?