> Все бы ничего, только они так и не ответили на вопрос: а что делать если так сложилась ситуация что данные и метаданные неконсистентны. Собссно все журналирующие ФС не нуждаются в fsck если гарантирована консистентность метаданных. И накукуй же они с fsck тогда поставляются? :)Этот вопрос адресуйте авторам этих других файловых систем.
> Просто разных гадостей которые могут случиться - навалом. И как бы ФС совсем не в минус если есть утиль способный собрать что-то хоть немного моунтабельное из той лапши которая есть. Потому что дискэдитором то колупать - как-то сильно более уныло и медленно, ага?
Дискэдитором колупать ничего не надо. Хотите примеров - почитайте zfs-discuss, масса примеров восстановления в самых разных ситуациях - от пула без репликации на сбойнувшем рэйд-контроллере, до RAID-Z с несколькими отказавшими дисками.
> Почему же, я этого не утверждал. Они, разумеется, существуют. Но у них есть довольно злые fsck которые достаточно упорно пытаются хоть что-нибудь отколупать. И даже половина данных но в моунтабельной ФС лучше чем слом мозга в дискэдиторе (таким макаром вы и половину не будете доставать, уж поверьте).
Угу, злые. Специально провел эксперимент - создал ext4, записал туда немного данных, отмонтировал и затер нулями суперблок и все его копии. Вуаля - злые fsck говорят, что нет там никакой ext2 (!!!) и в помине не было:
root@ubuntu:~# fsck -t ext4 -b 229376 /dev/md0
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: Invalid argument while trying to open /dev/md0
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Хотя казалось бы, чего тут сложного? Размер устройства известен, параметров, с которыми она была создана, не так уж много, метаданные в фиксированных местах. Перебери все варианты, и восстанови... Однако нет, пресловутая злая fsck (которая существует с момента начала жизни ext2, надо полагать) этого до сих пор не научилась делать. Сколько лет прошло? Десять? Больше?
> Пусть они скажут, а что будет если она не обеспечилась. Причин которые к этому приведут я могу придумать вагон. А вот что саночники предложат тогда делать?
Использовать zpool recovery support. Если не поможет - обращаться в zfs-discuss, так как этот zpool recovery support довольно консервативен.
>> тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее
>> сохранение этих консистентных состояних, это проблема этого диска.
> А я то, дебилко, думал что это проблемы юзера этого диска в конечном итоге :)
Проблемы юзера тоже, если он не озаботился наличием изыбточности
>> А также смотрим сюда:
>>http://mail.opensolaris.org/pipermail/onnv-notify/2009-Octob...
> Да, мы видим какой-то совсем недавний :D коммит чинящий судя по всему что-то вполне забавненькое - какой-то симпотный assert в парсинге ZIL. Т.е. как я понимаю, до этого коммита можно было схлопотать веселый assert в какой-то ситуации, ну и наверняка это было столь же приятно как серпом по йайцам :).И эти парни лечат что fsck не нужен, ага.
Сударь, если бы посмотрели чуть внимательнее, то заметили бы слона - поддержку восстановления пулов, добавленную этим коммитом. А не муху, которой является assert, неправильность которого была обнаружена при работе ztest, то есть в процессе тестирования, которым занимается каждый разработчик постоянно. Покажите аналоги ztest для других ФС? Много найдете?
> Как по мне - fsck в идеале должен быть утилью которая может пропарсить даже полуразрушенные структуры и восстановить все что было возможно восстановить в данных условиях, перестроив то что перестраивабельно и аннулировав потенциально конфликтные и проблемные метаданные, способные вызвать ругань драйвера ФС (ну, это в идеале). Т.е. том отданый утиле в абы каком состоянии должен прийти к консистентному состоянию, желательно с минимальными потерями данных. А заявы что у меня тома должны быть исправные - не в ладах со здравым смыслом. Да мало ли, может диск(и) настолько умерли что их еле-еле ремонтеры в дата рекавери лабе прочли, и то часть секторов - битые или пропущены, так что и ни о какой консистентности ФС спича более не идет? Случаи то разные бывают и с нахрапом втирать что данные всегда консистентны - наглость пиарщиков, не более.
Ответьте на один простой вопрос - как долго вы готовы ждать завершения работы fsck? Если она будет работать год, вы будете ждать?
Если вы готовы ждать долго, то почему злая fsck от ext2 из прошлого века, имевшая достаточно времени обзавестись восстановлением суперблоков путем полного перебора возможных параметров создания ФС, им до сих пор не обзавелась?
Видимо, это никому не надо. Вы же утверждаете, что без этого жить нельзя. Как же все без этого до сих пор жили?
Ждать дольше, чем время восстановления из бэкапа, нет смысла, а оно
а) конечно
б) известно заранее
> Так, для особо упертых braindead-ов молящихся на парней из Sun напоминаю: в *штатных* ситуациях, которые так красочно расписаны саночниками, у журнялирующих ФС логика журналирования тоже как бы вполне себе работает. И fsck им при этом нафиг не сдался при таких допущениях - оно при крахе быстро среплеит лог и - вуаля, ФС снова консистентна, можно моунтить и - вперед.
А в случае малейшей нештатности - fsck таки требуется. Если сбой произойдет в процессе проигрывания журнале - она тоже понадобится. А сколько на это уйдет времени на ФС размером в несколько десятков терабайт с сотнями миллионов файлов?
> Проблемы начнутся тогда когда это вдруг по какой-то причине не удалось или когда ФС почему-то попала в неконсистентное состояние в обход стандартной логики журналирования, etc. При том причин для этого - два зиллиона. И вот на такие случаи у других ФС есть отдельные тулсы, роль которых - попытаться починить порушенный том настолько насколько это возможно в даденых условиях. Хотя-бы потому что альтернатива в виде вытаскивания кусочков файлов с немонтируемого тома дискэдитором, парся остатки структур ФС в голове самолично заместо драйвера ФС - оптимизма обычно ни у кого не вызывает почему-то.
Заметьте, проблемы начнутся у всех. Только одни либо воспользуются zpool recovery support, чтобы вернуться на пару транзакций назад (потеряв часть данных), либо сразу пойдут восстанавливаться из бэкапов, другие же будут молиться, чтобы fsck что-нибудь исправила, потом, после нескольких неудачных попыток, им таки придется пойти восстанавливаться из бэкапов. Правда, к тому времени те, кто начал восстанавливаться раньше, возможно уже и закончат. Смысл? Бэкапов нет? На fsck уповали? Незачем было себя обманывать, рано или поздно, но взрослеть придется.
Наличие fsck не освобождает от необходимости иметь бэкапы. Или вы будете утверждать обратное?
> Разумеется, угробить можно все. Вот только почему-то остальные не вешают макароны на уши а выдают комплект утилей для починки их ФС "in the case of emergency". А вовсе не лечат про то как я не должен попадать в эти самые "emergency".
Можно точно так же сказать, что другие ФС "вешают макароны на уши" и создают видимость возможности восстановления "in case of emergency", предоставляя fsck, которая, даже если ей там и удастся что-то угадать, никак вам не гарантирует целостность "восстановленных" данных. Она может гарантировать только то, что метаданные ФС более-менее целостны с точки зрения fsck. При этом у ядра на этот счет может быть несколько иное мнение, поскольку fsck тоже может содержать ошибки, и в большинстве случаев код fsck не имеет ничего общего с кодом ядра. Для примитивных файловых систем типа extX синхронизацию кода fsck и кода ядра еще можно худо-бедно поддерживать, для более сложных ФС это может быть не так тривиально.
В случае ZFS при том или ином варианте восстановления ФС вам гарантирует (в рамках вероятности необнаружения ошибок используемого алгоритма контрольных сумм) целостность тех данных, к которым вы смогли получить доступ.
Что имеет смысл делать - так это выявлять наиболее часто встречающиеся на практике причины невозможности открытия пула, и работать над их устранением, причем лучше всего в онлайновом режиме. И над этим работают - недавний комит тому пример.
Вот этот вот CR - еще один пример:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6...
Заметьте, речь идет не об fsck, а о восстановлении на лету в процессе работы.
У вас есть еще конкретные примеры реально встречающихся на практике причин невосстановимых повреждений - вперед, баги на bugs.opensolaris.org можно открывать кому угодно. И от этого будет гораздо больше пользы, чем от пространных рассуждений на тему отсуствия fsck для ZFS и сферических конях в безвоздушном пространстве.
> И вот такой подход лично мне не понравился.
Это ваш выбор, вот только не нужно его никому навязывать.
