Делают ли экстенты файловую систему более надёжной?

Метаданные журналируются.

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

Журналирование для защиты от сбоев и нужно. Пишешь копию метаданных в журнал, sync. Пишешь метаданные на их место, sync. Пишешь в журнал об успешности транзакции, sync.

Да я понимаю что журнал для защиты от сбоев и нужен. Я понимаю как он может обеспечивать целостность данных. Однако мне непонятно как обеспечиваться целостность данных самого журнала. Скажем компьютер намеривался записать в журнал что-то вроде «записать в кластер такой-то такие-то данные». Компьютер стал записывать в журнал будущее содержимое кластера, но когда он принялся записывать содержимое кластера, которое надо будет в соответствии с журналом записать, произошло отключение электроэнергии. В результате компьютер записал только часть будущей записи в кластере, а остальная часть будет содержать случайный мусор. После перезагрузки компьютер посмотрит в журнал и запишет новое, неверное, содержимое кластера. И невдомёк будет бедняге, что на самом деле запись в журнале неверная, а следовательно и (мета)данные записаны неверно.

Куда уж им, машинам. Это ж нужно проверить, что запись в журнале есть, а метаданных нет. А то и чексуммы проверять. Не придумали таких штук ещё.

Для этого используются контрольные суммы, если журнал не дописан и контрольная сумма не посчитана, но журнал не верен

Посмотрите на опции на эту тему у ext4

Ну вот и я об том же. То есть ошибка может произойти и при журналировании. Вопрос в том кто при прочих равных будет более устойчив к возможному ущербу, ФС использующая экстенты или ФС без них?

Я думал использовать ext4 именно из-за этой плюшки, однако вся малина у меня обламалась когда я обнаружил что e2fsck в Debian Stable НЕ поддерживает именно эту фичу ext4.

А хотя выше пишут, что чексуммы уже придумали. Но оно всё равно ext4 неюзабельно. Вот когда они научится проверять журнал при монтировании, а лучше придумают инструмент для проверки консистентности данных/метаданных - вот тогда заживём!

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

Ты имеешь в виду ситуацию, в которой в диск послали одни данные, а записал он другие? Или ситуацию, когда запись в журнал была не окончена?

Не самом деле контрольные суммы пользуют все файловые системы Для разных целей.

А вообще нужно выбирать только экспериментом

Например jfs хвалили за супернадежность но в тестах оказалось что ее нельзя ставит на home, она тупо обнуляет поврежденные файлы

Если нужно именно устойчивость попробуйте xfs

Также можно nilfs2 изза ее специфики записи, но она еще недопилена

Не вникал в детали реализации ext4, но делал журналирование в дефрагментаторе для reiserfs.

Там запись в журнале состоит из трёх частей: блок описания транзакции, блоки для записи, коммит-блок. Блоки подготавливаются, посылаются на запись разом. Если запись в журнал была не завершена, то есть коммит-блок не записался, эта запись не будет действительной. Каждая транзакция имеет свой номер, поэтому вероятность понять данные неправильно очень мала.

Вопрос ставится не совсем корректно. Журнал не обеспечивает надежной записи, журнал лиш уберегает файловую систему от порчи при внезапном отключении питания.

Почуму может испортится ФС при сбое питания? Дело в том что в файловой системе много логически взаимосвязыных структур. Упрощенный пример: в некой абстрактной ФС есть два списка: FL список пустых блоков, и BL список занятых блоков. Некая операция требует перенос блока B1 из FL в BL. Для этого нужно изменить на диске как минимум два блока с метаданными (две операции записи): w1 - удаление B1 из FL, w2 - добавление B1 в BL. Если вдруг у нас пропадет питание так что w1 отработает, а w2 нет B1 станет потеряным блоком (его не будет не в одном списке) и файловая система будет нуждатся в полной верификации, после которой будет не совсем понятно к какому списку относить блок B1.

Но если у нас журналируемая ФС то перед модификацией списков файловая система вначале сделает запись в журнал (w0): Переносим блок B1 из FL в BL. После чего произойдет физический перенос блока (операции w1 и w2), и запись в журнале пометится как завершенная (w3). Если у нас произайдет poweroff на этапе выполнения w0 - то метаданные в ФС будут корректны (модификация не началась), если poweroff случится после w0 но до w3 то при загрузке драйвер ФС проверит чтобы B1 был именно в BL (и если это не так то быстро его туда перенесет) чем востановит корректность ФС.

А что если ошибка произойдёт в самом журнале?

Журнал используется только для отката.
Если данные в нем повреждены (то есть до записи данных еще даже не ошло), то такую запись можно просто игнорировать.

Ну есть режимы полного журналирования

Если данные в нем повреждены (то есть до записи данных еще даже не ошло), то такую запись можно просто игнорировать.

Это если ещё повезёт. А ведь всё может сложиться так (см. мой пост Делают ли экстенты файловую систему более надёжной? (комментарий)), что неправильную запись в журнале от правильной фиг отличишь, в резульате чего компьютер по ошибке совершит неправильные действия руководствуясь журналом.

Делают ли экстенты файловую систему более надёжной? (комментарий)

ИМХО описаная мной в посте ситуация подходит под оба критерия одновременно.

Ну тогда поставлю вопрос так: если в силу сложившихся обстоятельств запись в журнале будет неправильной, но при этом неотличимой от правильной (пример: Делают ли экстенты файловую систему более надёжной? (комментарий)), что в свою очередь вызовет повреждение целостности ФС или данных в ней хранящихся, то какая ФС при прочих равных и в среднем пострадает меньше, использующая экстенты или обходящаяся без них, при условии что журналируются как метаданные, так и данные (фактически как ext3 в режиме journal)?

см. мой пост Делают ли экстенты файловую систему более надёжной? (комментарий)

В посте чушь. Посмотри код любой журналируемой ФС.

Запись в журнале имеет контрольную сумму (даже банальный CRC32 обеспечит достаточную надёжность для данной задачи). Также запись в журнале удаляется (или как-то помечается) после выполнения операции.

Если запись будет записана в журнал не полностью, то контрольная сумма не сойдётся. Такую запись можно просто игнорировать, потому что запись в журнал происходит ПЕРЕД любыми изменениями метаданных. Если запись в журнал неудачна, то метаданные гарантированно не были тронуты.

Затем. Допустим, все операции выполнены, но запись в журнале удалить не успели. В этом случае происходит простая проверка - завершена ли операция (надо просто проверить прогнозируемое состояние метаданных после описанной операции и реальное). Если завершена, то удаляем запись, иначе откатываем недоделанные изменения.

Если же запись не полностью удалена, то контрольная сумма не сойдётся и её опять же можно игнорировать. Ведь удаление записи гарантированно начинается ПОСЛЕ всех изменений метаданных. То есть если запись в журнале некорректна, то это возможно лишь в двух случаях - данные ПОЛНОСТЬЮ не записаны или же данные ПОЛНОСТЬЮ записаны. В обоих случаях вмешательство не требуется (кроме чистки журнала от мусора).

Данные файлов, а не служебные структуры ФС обычно не журналируют (точнее журналируют аллокацию и освобождение блоков, но не их данные). Да-да. Сохранить данные, которые писались на диск в последние миллисекунды перед отключением питания, задачи не стоит. Такие данные (а также созданные и удалённые файлов) будут почти наверняка отброшены. Задача журналирования - сохранить корректность метаданных, чтобы не потерять все файлы вообще. В том числе ценой отката незавершённой операции.

Как я вижу процесс.
1. Добавляет запись в журнал «Записать данные в кластер Х; статус: незавершено». sync
2. Записываются данные в кластер Х. sync
3. Запись в журнале меняется как «завершено». sync

Если считать шаг 3 как атомарный, то есть который не может быть прерван на полдороги (а если данные маленькие, то так оно и есть), то прерывание на каждом шаге даст консистентные данные:
Прерывание на шаге 1 даст некорректную запись в журнале, оно просто будет проигнорировано/очищено.
Прерывание на шаге 2 даст откат в соответствии с данными журнала, то есть помечание кластера Х как «свободный» (и удаление записи из журнала).

Наверное, алгоритм посложнее, так как еще нужно проапдейтить запись о файле в ФС, но, думаю, там принцип тот же. То есть целосность можно гарантировать by design.

Ну тогда поставлю вопрос так: если в силу сложившихся обстоятельств запись в журнале будет неправильной, но при этом неотличимой от правильной

Такое возможно только в двух случаях: 1) Сломанное железо (битый винт или битая память) - и то вероятность стремится к нулю т.к. данные должны испортится очень хитрым способом так чтобы при этом сохранилась валидной структура данных и контрольные суммы 2) Ошибка в драйвере файловой системы. И то выполнение «битой» операции в журнале не приведет к поломке всей ФС, вы можете потерять какието данные (ошибочно удалится файл) но сама структура файловой системы будет целой и ей можно будет продолжать пользоваться.

при условии что журналируются как метаданные, так и данные (фактически как ext3 в режиме journal)

Я не знаю файловых систем где бы журналировались данные. В EXT3 журанлируются только метаданные, просто там журнал прикручен сбоку и реализован через запись в журнал целых блоков (тоесть в процессе модификации методанных драйвер записывает резервную копию блока (в котором хранятся методанные) в журнал (причем тратит для этого два блока внутри журнала), если тразакция не завршилась (power failure) то при следующем монтировании драйвер востановит все незакомиченные блоки из журнала. А при модификации данных внутри файла (без изменения размера файла) журнал не используется.

Я не знаю файловых систем где бы журналировались данные

Ext3/4 можно заставить журналировать данные, опция data=journal

Ну а CoW-ФС «журналируют» всё по определению.

Запись в журнале имеет контрольную сумму (даже банальный CRC32 обеспечит достаточную надёжность для данной задачи).

А разве такая фича есть у всех журналируемых ФС? Мне вообще-то казалось, что она доступна только у ext4 и возможно btrfs.

потому что запись в журнал происходит ПЕРЕД любыми изменениями метаданных

Ясно, что синхронизировать после каждой такой записи непрактично, значит используются какие-то write barriers? Иначе «ПЕРЕД» не факт.

Как это реализовано в Linux не знаю. Но чисто технически сам жёсткий диск пишет данные в таком порядке, в каком ему отправили команды записи. Это вам не UDP, тут гарантируется, что команды по SATA придут в таком же порядке, в каком их отправил процессор на контроллер интерфейса. В ядре Linux, разумеется, имеется буферизация, чтобы писать данные большими кусками. Но ничто не мешает дать возможность драйверу ФС давать подсказки, какие команды менять местами нельзя. Или буферизация может быть реализована на другом уровне (буферизуются команды к драйверу ФС, сам драйвер всегда работает с диском синхронно). Как именно всё происходит - лучше спросить у человека, который ковырялся в ядре.

Но чисто технически сам жёсткий диск пишет данные в таком порядке, в каком ему отправили команды записи

Позвольте с Вами не согласиться. Насколько я знаю, у самого жёсткого диска тоже может быть буфер, который причём существует независимо от буфера ОС. И тут вся надежда на то, что ОС сможет прямо приказывать диску записывать одни данные раньше других (barriers=1 фактически). А ведь если прошивка у жёсктого диска кривая, то диск может своевольничать и сделать что-то не так, как ОС от него ожидала.

Но чисто технически сам жёсткий диск пишет данные в таком порядке, в каком ему отправили команды записи.

Это было до SATA II (2003-2004), в который для оптимизации перемещения головок ввели NCQ, что совсем неплохо. Не проверял, но надеюсь, что и подходящие барьеры тоже там есть и используются драйвером ФС.

А ведь если прошивка у жёсктого диска кривая, то диск может своевольничать и сделать что-то не так, как ОС от него ожидала.

С такими ошибками просто невозможно считаться. Задача разработчиков следовать документации и предпринимать всё необходимое теоретически для сохранности данных. Разве что в режиме «параноик»: иметь буфер для записи, который после записи спустя некоторое время сравнивается с данными, которые начисто были перечитаны с диска. После цикла отключения/включения питания. На всякий случай.

Конечно, если что-то задокументировано в errata, то это уже другое дело.

Помогает обычно raid или репликация в комапании bit scrubbing.