> у меня в 2012 году на zfs при хитрой комбинации архивирования и
> распаковки - распакованные файлы имели мусор, но размеры файлов при этом
> соответствовали оригинальным - после этого я не на zfs - и
> очередной раз проверять это - нет желания.У меня есть желание проверить этот ваш use case. Дайте план что ли.
>>> на ufs чуток другая история с переписанным SU - не работает абсолютно
>>> sync - то есть оно работает, но через 60 секунд -
>>> если за эти 60 секунд данные не сброшены на носитель+непредвиденная ситуация
>>> и паника/отключение питания/любой другой сбой по питанию - считай - данные
>>> утеряны...
>> Метаданные возьмутся из предыдущего снапшота. Потеряется только зарезервированное под
>> новые данные место.
> а если его нет на момент факапа? разве таких случаев быть не может?
Метаданные при SU обновляются транзакционно. Это на уровне архитектуры ФС вопрос решённый. Другое дело, что sync в Linux несовсем корректно работает, может вы с ним спутали?
> я не говорю о резервном копировании и тп - я говорю о
> багах, которые практически неуловимые по причине нежелания/халатности/безответственности/нехватки ресурсов/еще чего-то
Дайте ваш план проверки и подтверждения потери данных на ФС. А то одни общие слова.
>>> SUJ - как было поломанным от рождения - так с тех пор
>>> ничего не изменилось - либо не хватает ума разобраться в чужом
>>> коде, либо желания.
>> А что там не так?
> нихрена он не выполняет свои функции - после сбойной перезагрузки предлагает восстановить
> по журналу - процесс идет, но файлы утеряны, и судя по
> всему что из-за комплексных взаимопричин.
SU+J не относится к журналированию данных. Это механизм защиты метаданных и быстрого восстановления места на диске, выделенного под запись новых данных. Многие путают снапшоты на UFS2 с возможностью восстановления данных. Это не так. Транзакционная защита (SU) гарантируется только для метаданных файловой системы, а файлы останутся в том состоянии, в каком они были в момент сбоя. Журналирование (J) позволяет восстанавливать непротиворечивое состояние метаданных очень быстро, избегать фоновой проверки при загрузке. "Потерянные цепочки" в файлах каталога lost+found — это результат приведения в соответствие метаданных с хранящимися данными после сбоя, как в любых классических *nix ФС.
>>> после fsck UFS - lost+found зачастую пуст, а в тех файлах, что по идее должно что-то быть - размер 0.
>> Значит транзакция записи в эти файлы была аварийно прервана. Потерянные цепочки —
>> это выделенное место под новые файлы, которые не записались из-за аварийного
>> сбоя. Метаданные починились откатом к последней завершённой транзакции. Так работает Soft-Updates
>> — ничего страшного в этом нет.
> если есть возможность ситуации при которой возможна потеря данных в легко воспроизводимой ситуации - это ничего страшного - то мне не о чем больше с тобой говорить.
В какой такой "легко воспроизводимой ситуации", примеры потерь есть?
> меня не волнуют алгоритмы используемые в этих процессах - система не должна
> мне диктовать суровые рамки ограничений в ее использовании, что касается фс,
> кроме остатка свободного места на ней.
Так называемые "суровые рамки использования" это: снижение быстродействия дисковых операций по сравнению с теми ФС, где таких "рамок" вообще нет (Ext2) или они довольно зыбки (Ext3, Ext4).
> меня в контексте этой темы - линукс вообще не волнует - я говорю о слабых сторонах FreeBSD как целостного, организованного, ответственного проекта, который имеет какие-то определенные планы и методы развития - хочется в это верить.
О слабых сторонах процесса разработки можно говорить долго. Важен сам результат: в GNU/Linux гонятся за гламуром и глянцем внешнего вида, пуская по-настоящему важные вещи на самотёк; во FreeBSD во главу угла ставится надёжность и предсказуемость.
