> В этом и заключается один из аспектов стабильности - когда файловая система
> прописывается в fstab, как ожидается, а потом выясняется, что в какой-то
> момент все ломается и запускаемый при запуске fsck ничего не делает А тут все просто: логика работы разных ФС - весьма разная. Поэтому попытки их всех под одну гребенку - имеют свои, скажем так, особенности и странности :).
Как таковой fsck в его классическом понимании, выполняемый при загрузке ОС - имел смысл для нежурналируемых ФС. Потому что корректность метаданных при крахе не гарантирована. Журналируемые ФС так или иначе должны приходить в консистентное состояние без залета на fsck. В этом пойнт журнала и состоит, ибо время ребута измеряемое часами почему-то вызывает возражения. Если журналом отыграть в консистентное состояние не получилось - это существенный развал механики ФС (бэд сектора и прочие нестандартные ситуации) или серьезный баг (некорректное журналирование, etc). Дальнейшие действия по починке или data recovery - вероятно потребуют человеческого внимания и интерактивной процедуры. Кроме всего прочего - полное сканирование всех метаданных немеряного стоража может занять буквально часы. Ждать загрузки системы ЧАСАМИ - на любителя.
> кодом 1 (reiserfs), это становится проблемой само по себе.
Как таковой "один fsck во все щели" - вполне себе повод для дебатов. Не укладывающееся в многие юзкейсы решение. Мало кому нравится время загрузки сервака с большим сторажем в пять часов. А хомяк на мобилке - не сделает интерактивное восстановление ФС, хоть там что. Там ФС должна сама отбрыкаться. А если не смогла - уже минимум рефлеш. А то и поход в гарантийку. А fsck при загрузке там никому не уперся.
> в голове у разработчиков (и думали ли они вообще о принятых в мире linux вещах),
В Linux не принято пи...ть новичков по причине "здесь так принято". И юзкейсов у Linux немеряно. Вон у squashfs - что должен делать fsck, например? А для initrd - нужен fsck?
> но внедрению в качестве универсальной ФС это мешает очень сильно.
В случае рейзера - мешает скорее общее сочетание факторов. В случае btrfs - да в общем то уже ничего не мешает. Но некоторые подходы там иные. Частично по мотивам zfs.
> Можно, конечно, переучить пользователей: в том же ZFS потратили до фига сил
> на популяризацию, почему fsck не нужен.
ИЧСХ, в _этом_ дизайне _некоторый_ пойнт в этой мысли есть. Скорее всего - восходящий к мысли что 5 часов чекать невъ...й стораж до того как сервак вообще стартанет - так себе идея. Намного логичнее попробовать прицепить стораж, чтобы он стал доступен, а метаданные сканировать в фоне. Другое дело что эти умники сначала только вопили про сферические идеальные случаи в вакууме, а план Б на случай если все-таки не вышло - у них был не проработан. И поэтому перец с Лисяры закатывал солнце вручную, хексэдитором. Не больно то приятно в навороченной файлухе хексэдитором колупаться лишний раз.
> Ну так там вообще революционный подход, и в vfstab прописывать не нужно..
А btrfs чем-то похож в этом плане - для него fstab понятие растяжимое. Он на ходу может менять из каких девайсов пул составлен. В этом плане подход с fstab просто не маппится 1 в 1. Да и например - ну вот надо мне rootfs смонтировать. Для того чтобы прочитать fstab ... надо чтобы rootfs уже был. Яйцо и курица, однако. Поэтому rootfs зачастую указывается где-то сбоку.
