>[оверквотинг удален]
>>>> http://docs.freebsd.org/cgi/mid.cgi?CACpH0MeAvs6rzWUo3uF8uTy...
>>>> http://docs.freebsd.org/cgi/mid.cgi?etPan.5446c5a2.78f17764....
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513
>>>> http://docs.freebsd.org/cgi/mid.cgi?543FAB3C.4090503
>>>> и это только по ZFS и только за пару последних недель...
>>> Есть некие нештатные ситуации использования, в которых срабатывают блокировки ядра или
>>> сыпется железо на -CURRENT или устаревших (9.2) версиях FreeBSD. А где
>>> прямые потери данных на ZFS и UFS?
>> ну во-первых про потери речи не шло
> А зачем тогда выпячивать специфические случаи?кто выпячивает? прочность цепи характеризуется ее наиболее слабым звеном!
>> во-вторых всё в той же рассылке у людей разваливаются zraid массивы при
>> нормальных носителях (проверялись отдельно) и восстановление или настолько не тривиально,
>> или невозможно средствами zfs восстановления/проверки - чем не потеря данных?
> Я увидел: резильверинг на одном из 20 физических носителей в raidz1, отданного,
> судя по названию пула, под торрент. Так это не потеря, а
> онлайн процесс верификации возможной потери данных на одном из осыпающихся носителей.
я не конкретно о ссылках что дал выше.
у меня в 2012 году на zfs при хитрой комбинации архивирования и распаковки - распакованные файлы имели мусор, но размеры файлов при этом соответствовали оригинальным - после этого я не на zfs - и очередной раз проверять это - нет желания.
>> на ufs чуток другая история с переписанным SU - не работает абсолютно
>> sync - то есть оно работает, но через 60 секунд -
>> если за эти 60 секунд данные не сброшены на носитель+непредвиденная ситуация
>> и паника/отключение питания/любой другой сбой по питанию - считай - данные
>> утеряны...
> Метаданные возьмутся из предыдущего снапшота. Потеряется только зарезервированное под
> новые данные место.
а если его нет на момент факапа? разве таких случаев быть не может?
я не говорю о резервном копировании и тп - я говорю о багах, которые практически неуловимые по причине нежелания/халатности/безответственности/нехватки ресурсов/еще чего-то
>> SUJ - как было поломанным от рождения - так с тех пор
>> ничего не изменилось - либо не хватает ума разобраться в чужом
>> коде, либо желания.
> А что там не так?
нихрена он не выполняет свои функции - после сбойной перезагрузки предлагает восстановить по журналу - процесс идет, но файлы утеряны, и судя по всему что из-за комплексных взаимопричин.
>> после fsck UFS - lost+found зачастую пуст, а в тех файлах, что по идее должно что-то быть - размер 0.
> Значит транзакция записи в эти файлы была аварийно прервана. Потерянные цепочки —
> это выделенное место под новые файлы, которые не записались из-за аварийного
> сбоя. Метаданные починились откатом к последней завершённой транзакции. Так работает Soft-Updates
> — ничего страшного в этом нет.
если есть возможность ситуации при которой возможна потеря данных в легко воспроизводимой ситуации - это ничего страшного - то мне не о чем больше с тобой говорить.
меня не волнуют алгоритмы используемые в этих процессах - система не должна мне диктовать суровые рамки ограничений в ее использовании, что касается фс, кроме остатка свободного места на ней.
>> для того что бы наступать на те же грабли - системой нужно
>> пользоваться не в ознакомительных целях - а плотно и постоянно использовать
>> во всех прикладных задачах + бывают частные случаи, которые встречаются крайне
>> редко для набора статистики и возможности воспроизведения кем-то другим, кто знает
>> слово "FreeBSD".
> Инфраструктура FreeBSD и работает на самой себе, а не на линуксах каких-то.
в инфраструктуре задачи узконаправленные и как правило не меняются изо дня в день, или месяцы.
>> при более ответственном отношении к коду и системе в целом - таких бы тенденций вообще не было бы.
> При более ответственном отношении к системам хранения данных в Btrfs давно была
> бы возможность использовать RAID-5 и RAID-6 штатно в продакшене. Но её
> почему-то нет и неизвестно, когда будет. А в ZFS эти вещи
> были изначально заложены и реализованы. И с успехом применяются каждодневно на
> большом числе серверов (в том числе на GNU/Linux со сторонним модулем).
> Так что: "при более ответственном отношении к коду и системе в
> целом - таких бы тенденций в GNU/Linux, в частности в Btrfs,
> вообще не было бы."
меня в контексте этой темы - линукс вообще не волнует - я говорю о слабых сторонах FreeBSD как целостного, организованного, ответственного проекта, который имеет какие-то определенные планы и методы развития - хочется в это верить.
