Поцоны из openzfs — скорострелы

А что там в Illumos?

Лично я до сих пор на ZFS v0.8.6

Это все линуксоиды. С одной стороны привносят новые фичи в ZFS на которые у BSD/Illumos не было времени/ресурсов, а с другой стороны развели бардак в коде свойственный всему к чему прикасаются.

Так бы и остался на 12-й фряхе где православный ZFS. А так, приходится юзать 14 из-за нового железа и фич.

А может быть, это проделки Oracle и других околокорпоративных троллей? :)

Вариант сценария (просто предположение, все персонажи вымышленные):

1. Ларри предупредил отдел соляристов, что нужно как-то стимулировать продажи Oracle Solaris, иначе корпоративные пенсии могут быть урезаны, и увожаемые люди смогут реже посещать самые дорогие пляжи Флориды, а то и вовсе придётся квасить пивас в своём redneck задрищинске.

2. Старпёры, всю жизнь проработавшие над ZFS с момента её зарождения ещё около 20-и лет назад, любившие Sun всем своим сердцем, и так же ненавидившие северных пингвинов, которые сожрали их солнечную империю, решают нанести ответный удар :)

3. Они подробно изучили сорцы OpenZFS и разработали стратегию взаимодействия с этим досадным проектом. Суть стратегии: 3.1) Заимствовать хорошие идеи к себе в Oracle ZFS 3.2) Пытаться навредить развитию и репутации OpenZFS в лучших традициях ганстолкеров.

4. Изучили наиболее актуальные проблемы OpenZFS, с которыми проект не может справиться сам

5. Покровители Ларри из ЦРУ подыскали старпёрам аватара-вредителя разработчика с горящими глазами, готового покорять мир. Сам он в лучших традициях спецслужю ессно даже и не знал о таком интересе к себе со стороны тайных доброжелателей :)

6. Молодая звезда разработки внедряется в ZFS почти по собственному желанию, кроме того он активно общается в чатиках разработчкиков, где в т.ч. тусят и нужные люди от ЦРУшных Oracle старпёров, занятых работой над увеличением взносов а американский пенсионный фонд имени Ларри и Ко. Сам он даже не в курсе, что очутился в проекте OpenZFS не случайно, а под воздействием группы влияния и постоянном надзоре со стороны ЦРУ.

7. Доброжелатели активно помогают юноше развиваться, дают ценные идеи, и даже подбрасывают фрагменты кода. Это позволяет молодому дарованию втереться в доверие айти босов Los Alamos, и те разрешают ему заниматься важными и очень сложными фрагментами ZFS, которые другие не могут осилить.

8. ЦРУ и АНБ известны своими талантами и достижениями в разработке невидимых закладок, которых как бы нет, но они всё же есть, и когда встречается определённая последовательность байтов, появление которых маловероятно в обычных естественных условиях, информационная система начинает вести себя несколько иначе в той или иной степени, в зависимости от кого, какую последовательность выбрали для активации закладок. Таких последовательностей (бомб замедленного действия) может быть заложено десятки, а активируют постепенно по мере развития общеполитической ситуации и приближения своего пенсионного возраста.

9. Oracle как и IBM начинают любезно и щедро раздавать свои OS другим молодым юношам, подающим нужные надежды корпорациям, что популяризирует источники будущих пенсионных доходов.

Как вам такая «теория заговора»? ;)

слишком сложно

Немного улучшенная версия, не успел отредактировать старую :)

А может быть, это проделки Oracle и других околокорпоративных троллей? :)

Вариант сценария (просто предположение, все персонажи вымышленные):

1. Ларри предупредил отдел соляристов, что нужно как-то стимулировать продажи Oracle Solaris, иначе корпоративные пенсии могут быть урезаны, и увожаемые люди смогут реже посещать самые дорогие пляжи Флориды, а то и вовсе придётся квасить пивас в своём redneck задрищинске.

2. Старпёры, всю жизнь проработавшие над ZFS с момента её зарождения ещё около 20-и лет назад, любившие Sun всем своим сердцем, и так же ненавидившие северных пингвинов, которые сожрали их солнечную империю, решают нанести ответный удар :)

3. Они подробно изучили сорцы OpenZFS и разработали стратегию взаимодействия с этим досадным проектом. Суть стратегии: 3.1) Заимствовать хорошие идеи к себе в Oracle ZFS 3.2) Пытаться навредить развитию и репутации OpenZFS в лучших традициях ганстолкеров.

4. Изучили наиболее актуальные проблемы OpenZFS, с которыми проект не может справиться сам

5. Покровители Ларри из ЦРУ подыскали старпёрам аватара-вредителя разработчика с горящими глазами, готового покорять мир. Сам он в лучших традициях спецслужб ессно даже и не знал о таком интересе к себе со стороны тайных доброжелателей :)

6. Молодая звезда разработки внедряется в ZFS почти по собственному желанию, кроме того он активно общается в чатиках разработчкиков, где в т.ч. тусят и нужные люди от ЦРУшных Oracle старпёров, занятых работой над увеличением взносов в американский пенсионный фонд имени Ларри и Ко. Сам он даже не в курсе, что очутился в проекте OpenZFS не случайно, а под воздействием группы влияния и постоянном надзоре со стороны ЦРУ.

7. Доброжелатели активно помогают юноше развиваться, дают ценные идеи, и даже подбрасывают фрагменты кода. Это позволяет молодому дарованию втереться в доверие айти босов Los Alamos, и те разрешают ему заниматься важными и очень сложными фрагментами ZFS, которые другие разработчики осилить не могут.

8. ЦРУ и АНБ известны своими талантами и достижениями в разработке невидимых закладок, которых как бы нет, но они всё же есть, и когда встречается определённая последовательность байтов, появление которых маловероятно в обычных естественных условиях, информационная система начинает вести себя несколько иначе в той или иной степени, в зависимости от того, какую последовательность выбрали для активации закладок. Таких последовательностей (бомб замедленного действия) может быть заложено десятки, а активируют их постепенно по мере развития общеполитической ситуации и приближения своего пенсионного возраста.

9. Oracle как и IBM начинают любезно и щедро даром раздавать свои OS другим молодым юношам, подающим нужные надежды корпорациям, что популяризирует источники будущих пенсионных доходов.

Как вам такая «теория заговора»? ;)

Это все линуксоиды.

Под чутким контролем увожаемых людей.

С одной стороны привносят новые фичи в ZFS на которые у BSD/Illumos не было времени/ресурсов,

Сразу несколько зайцев.

а с другой стороны развели бардак в коде свойственный всему к чему прикасаются.

Старались, однако, рады, что вам понравилось. LOL

Так бы и остался на 12-й фряхе где православный ZFS. А так, приходится юзать 14 из-за нового железа и фич.

Бинго, переходи на временно бесплатный Oracle Solaris ;)

Пересказ ни о чём, экспертные выводы тоже. И вообще обсудили уже в В OpenZFS выявлена ошибка, которая может привести к повреждению файлов

Предыстория ошибки хорошо расписана в https://github.com/openzfs/zfs/pull/15571, там же предполагаемый фикс

Очень интересная, товарищ sanyo1234-GPT

ZFS фанбои что с лицом?

У меня такое ощущение, что я это недавно уже писал.

SmartOS тоже? Которая для ынтырпрайз клаудов, btw.

Как вам такая «теория заговора»? ;)

Зря ты игнорируешь предписание лечащего врача и не пьешь таблетки

там же предполагаемый фикс

Второй по счету :))

Stanson — агрессивный ламер

hateWin - тролль, имитирующий своим поведением латентного имбецила?

Найс разрыв

предполагаемый фикс

Второй по счету

Ну может ещё не последний, история не закончилась пока.

• Ошибка появилась сильно раньше релиза 2.2.0, просто вероятность испортить данные в предыдущих релизах было сильно ниже.
• Выключение фичи клонирования блоков в 2.2.1 не является полноценным фиксом
• Нормальный фикс начали готовить примерно сразу после выхода 2.2.1, да всё пока никак

Пропустили неизвестно когда ошибку с тихой потерей данных, а теперь ещё и поправить не могут, кошмар!

Сделали простой скрипт для поиска потенциально битых файлов на zfs: https://github.com/openzfs/zfs/issues/15526#issuecomment-1826248282

(Поиск 4к нулей подряд).

Выпустили исправление OpenZFS https://github.com/openzfs/zfs/pull/15571

похоже, reproducer.sh больше не работает после этого патча. Там народ пытается выдать экстремальные нагрузки чтобы увеличить вероятность срабатывания, но пока ни у кого с 15571 не получилось.

Ещё:

After downgrading coreutils from 9.3 to 8.32, I am no longer able to reproduce this corruption.

ZFS фанбои что с лицом?

У меня след от фейспалма останется надолго…

In ancient Greek mythology, Python was a serpent that lived at the center of the Earth and was believed to guard the oracle at Delphi

Они бы уже сделали сначала нормальную v2.0.latest, где пофикшены все известные баги, а не городили базар, похожий на басню Крылова.

Горшочек, не вари!

nox на opennet добавил полезную информацию (грамматика и орфография автора):

Ну и вкратце реальный источник ошибки - успехов местным васянам найти его «git blame» - как найдете, свистните. Тут в freebsd 12 очень нужно (к ней не подойдет 15571). При копировании файла большинство реализаций cp (а заодно tar и дофига кто еще) используют специфический метод для обнаружения в нем дыр и создания вместо нулей нераспределенных блоков которые копировать или сохранять незачем. Это НЕ чтение и сравнение с нулем, такое бы сработало как надо, но читать пару гигабайт ничего чтобы убедиться что там нули - немного глупо, и у большинства fs есть для этого отдельная фича в lseek.

Вот в ее реализации - обмишулились чуток. Да, во времена иллюмоса еще. Или даже швятога sun - но это неточно. И если дергать SEEK_HOLE на файле половина которого еще висит где-то в кэшах и не долетела до диска - можно ненароком найти несуществующую. (так что таки привет hole_(re)birth - реинкарнировалась десять лет спустя, падла)

Т.е, существующие данные потерять таким образом нельзя, повреждена будет только копия. Чтобы получить такую поврежденную копию - нужно скопировать файл ДВАЖДЫ - второй раз - сделав копию копии, причем достаточно быстро чтобы вторая копия еще не успела до конца дописаться - тогда третья оказывается несовпадающей.

Рефлинки никак с этим не связаны. Если там и есть баг - он отдельный.

Нули необязательны как признак поврежденного файла - может точно так же неправильно сработать и SEEK_DATA (т.е. наоборот - вместо законных нулей получить билиберды)

dmu_offset_next_sync связана только тем, что это оказалось вредное «улучшение», не улучшавшее как думали, а ухудшавшее производительность при множественной параллельной записи (т.е. просто оставляло больше шансов на возникновение race, но он таки возникает и при 0, просто надо сильнее грузить систему)

Сборка игого попала под раздачу именно потому что без конца копирует одни и те же файлы, их много, и параллельная сборка сильно грузит fs, игого и рач не виноваты, странно но тоже факт.

На мой кейс (диски виртуалок, в основном) эта проблема не распространяется:

Т.е, существующие данные потерять таким образом нельзя, повреждена будет только копия. Чтобы получить такую поврежденную копию - нужно скопировать файл ДВАЖДЫ - второй раз - сделав копию копии, причем достаточно быстро чтобы вторая копия еще не успела до конца дописаться - тогда третья оказывается несовпадающей.

Они бы уже сделали сначала нормальную v2.0.latest, где пофикшены все известные баги, а не городили базар, похожий на басню Крылова.

Имхо в реальных крупных проектах так не делают (нет смысла фиксить вообще все баги, заведённые в багтрекере).

К чему не притронутся линуксоиды — всё превращается в ненужное г..но.