>Это вы технично передергиваете в этом моменте, а парни из Сана рекомендуют
>предоставить ZFS возможность контролировать уровень избыточности.Парни из сана судя по стилю спича просто технично прикрывают свои жопы и пиарятся.
Чувакам вопрос:
- А почему у вас нет fsck?
Чуваки в ответ:
- Мы умеем так, мы умеем сяк и вот этак. И вообще у нас тут CoW, навороты, блаблабла. Но вы должны использовать правильное железо! Блаблабла.
Все бы ничего, только они так и не ответили на вопрос: а что делать если так сложилась ситуация что данные и метаданные неконсистентны. Собссно все журналирующие ФС не нуждаются в fsck если гарантирована консистентность метаданных. И накукуй же они с fsck тогда поставляются? :)
>Метаданные, помимо избыточности вроде зеркал или RAID-Z,
>хранятся в нескольких экземплярах (два или три) за счет
>использования дубль-блоков. Плюс, админы локалхоста могут включить дубль-блоки
>для своих данных даже на одном диске.
Мне все нравится, кроме одного: тепличные допущения "а подыграем ка мы себе, выбрав удобные правила игры и допустив что метаданные всегда валидны, забив на неудобный случай когда это не так" - сосут. В идеальном мире - да, оно катит. В реальном - на диске может быть что угодно, т.к. железо - сбоит, софт - с багами, так что пиндеж саночников неубедителен.
>чтобы они попали во все копиии дубль-блоков, а это уже
>гораздо менее вероятно.
Просто разных гадостей которые могут случиться - навалом. И как бы ФС совсем не в минус если есть утиль способный собрать что-то хоть немного моунтабельное из той лапши которая есть. Потому что дискэдитором то колупать - как-то сильно более уныло и медленно, ага?
>И потом, не будете же вы утверждать, что не существует набора неудачных
>бэд-блоков, которые приведут какую-нибудь ext3/ext4 в непригодное состояние?
Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать. И даже половина данных но в моунтабельной ФС лучше чем слом мозга в дискэдиторе (таким макаром вы и половину не будете доставать, уж поверьте).
>Много бухтите тут, скорее, вы. Консистентность состояния на диске обеспечивается
Пусть они скажут, а что будет если она не обеспечилась. Причин которые к этому приведут я могу придумать вагон. А вот что саночники предложат тогда делать?
>тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее
>сохранение этих консистентных состояних, это проблема этого диска.
А я то, дебилко, думал что это проблемы юзера этого диска в конечном итоге :)
> Так что повторяем еще раз - с головой даем ZFS контролировать уровень избыточности.
Все это левые отмазы, т.к. не отвечает на вопрос - а что делать если консистетности все-таки кранты? Допущение что "такого не бывает" не выдерживает никакой критики, поскольку методом "от противного" легко воссоздаются ситуации когда это будет не так. Т.е. эти ситуации не являются невозможными и даже - воссаздавабельны за разумное время на планете Земля.Т.е. ничто не мешает им в принципе произойти и самим по себе, "если не повезло".
> А также смотрим сюда:
>http://mail.opensolaris.org/pipermail/onnv-notify/2009-Octob...
Да, мы видим какой-то совсем недавний :D коммит чинящий судя по всему что-то вполне забавненькое - какой-то симпотный assert в парсинге ZIL. Т.е. как я понимаю, до этого коммита можно было схлопотать веселый assert в какой-то ситуации, ну и наверняка это было столь же приятно как серпом по йайцам :).И эти парни лечат что fsck не нужен, ага.
Как по мне - fsck в идеале должен быть утилью которая может пропарсить даже полуразрушенные структуры и восстановить все что было возможно восстановить в данных условиях, перестроив то что перестраивабельно и аннулировав потенциально конфликтные и проблемные метаданные, способные вызвать ругань драйвера ФС (ну, это в идеале). Т.е. том отданый утиле в абы каком состоянии должен прийти к консистентному состоянию, желательно с минимальными потерями данных. А заявы что у меня тома должны быть исправные - не в ладах со здравым смыслом. Да мало ли, может диск(и) настолько умерли что их еле-еле ремонтеры в дата рекавери лабе прочли, и то часть секторов - битые или пропущены, так что и ни о какой консистентности ФС спича более не идет? Случаи то разные бывают и с нахрапом втирать что данные всегда консистентны - наглость пиарщиков, не более.
Так, для особо упертых braindead-ов молящихся на парней из Sun напоминаю: в *штатных* ситуациях, которые так красочно расписаны саночниками, у журнялирующих ФС логика журналирования тоже как бы вполне себе работает. И fsck им при этом нафиг не сдался при таких допущениях - оно при крахе быстро среплеит лог и - вуаля, ФС снова консистентна, можно моунтить и - вперед.
Проблемы начнутся тогда когда это вдруг по какой-то причине не удалось или когда ФС почему-то попала в неконсистентное состояние в обход стандартной логики журналирования, etc. При том причин для этого - два зиллиона. И вот на такие случаи у других ФС есть отдельные тулсы, роль которых - попытаться починить порушенный том настолько насколько это возможно в даденых условиях. Хотя-бы потому что альтернатива в виде вытаскивания кусочков файлов с немонтируемого тома дискэдитором, парся остатки структур ФС в голове самолично заместо драйвера ФС - оптимизма обычно ни у кого не вызывает почему-то.
>Опять же, надеюсь, что вы не будете утверждать, что сбоящие процессор или
>память не могут привести другую файловую систему непригодное состояние.
Разумеется, угробить можно все. Вот только почему-то остальные не вешают макароны на уши а выдают комплект утилей для починки их ФС "in the case of emergency". А вовсе не лечат про то как я не должен попадать в эти самые "emergency". И вот такой подход лично мне не понравился.
