LINUX.ORG.RU
ФорумTalks

В OpenZFS выявлена ошибка, которая может привести к повреждению файлов

 , , ,


1

4
Доступен промежуточный выпуск проекта OpenZFS 2.2.1, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Выпуск примечателен добавлением поддержки ядра Linux 6.6 и попыткой устранения проблемы, приводящей к повреждению данных (обнулению части блоков) в файлах после их копирования.

Изначально предполагалось, что проблема проявляется только в ветке 2.2.x и вызвана ошибкой во включённом в OpenZFS 2.2.0 механизме клонирования блоков, позволяющем создать копию файла или его части без дублирования данных, используя во второй копии ссылки на уже существующие блоки данных исходного файла без их фактического копирования. В версии OpenZFS 2.2.1 для блокирования проблемы механизм клонирования блоков был отключён по умолчанию, а для возвращения поддержки данного режима добавлена настройка zfs_bclone_enabled.

Позднее разработчики заявили о воспроизведении проблемы и в конфигурациях с веткой OpenZFS 2.1.x. Не подтвердились и предположения, что проблема проявляется на системах со старыми выпусками пакета coreutils - ошибку удалось воспроизвести во FreeBSD и в Linux-дистрибутивах со свежим выпуском coreutils 9.4.

Повреждение файлов проявляется при достаточно редком стечении обстоятельств, например, выполнение в Gentoo команды "emerge -1 dev-lang/go" приводит к установке инструментария для языка Go с повреждением файлов в каталоге /usr/lib/go/pkg/tool/linux_amd64/compile. Предполагается, что ошибка начала проявляться после выставления по умолчанию параметра "zfs_dmu_offset_next_sync=1" в версии openzfs 2.1.4. Источник ошибки пока не выявлен. В качестве рекомендованного обходного пути блокирования ошибки предложено выставить в 0 параметр "/sys/module/zfs/parameters/zfs_dmu_offset_next_sync". 

https://www.opennet.ru/opennews/art.shtml?num=60167

EXT4-БОЯРЕ НА МЕСТЕ?



Последнее исправление: MoldAndLimeHoney (всего исправлений: 1)

Ответ на: комментарий от u5er

Экст4 чем не нравится

Не нравится возможностью исчерпания инодов.

Вы такое в живую хоть раз видели?

anc ★★★★★
()
Ответ на: комментарий от harbinger

Есть аппаратные контроллеры

Стоят нууу очень неприлично.

школоадм

А это что за зверь?

anc ★★★★★
()
Ответ на: комментарий от GAMer

Которые не знают ничего про низлежащую ФС.

И не должны.

Банальный вопрос про рассинхронизацию зеркала для них неразрешим.

Поясните пожалуйста.

anc ★★★★★
()
Ответ на: комментарий от harbinger

просто после того как майнинг чихуахуа приказал долго жить, на вторичке оказалось огромное количество контроллеров и сравнительно небольших хардов (300гб-4тб) за копейки.

Вы покупаете бу харды?

anc ★★★★★
()
Ответ на: комментарий от yu-boot

Зачем на ноуте в 2023 что-то кроме удалённого доступа?

Вы ноут с планшетом не перепутали? Ну и что бы два раза не вставать, в вашем параллельном 2023 весь шарик покрыли высокоскоростным на 1046% бесперебойным, безлимитным и ооочень дешевым инетом?

anc ★★★★★
()
Ответ на: комментарий от ox55ff

Не зря я на btrfs сижу. Тут таконо нет.

Потому что недообследованное.

iZEN ★★★★★
()
Ответ на: комментарий от TheNewDragon

Мамкин одмин локалхоста...

Ну зачем так строго? Человек когда-то, где-то, прочитал про это... запомнил... и теперь жутко боится! ... на всякий случай... :) Но если серьезно, то потенциально такой вариант возможен... Но потенциально... :)

anc ★★★★★
()
Ответ на: комментарий от anc

Поясните пожалуйста.

Если есть аппаратный контроллер и, скажем, пара дисков в зеркале, то, если в силу каких-то причин, содержимое дисков станет различным, контроллер не будет знать, какие данные на каком диске актуальны, а для zfs это не проблема.

GAMer ★★★★★
()
Ответ на: комментарий от anc

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

u5er
()
Ответ на: комментарий от TheNewDragon

Мамкин одмин локалхоста

И горжусь этим! Нет, правда: у меня есть свобода выбора. Я могу делать на своём компьютере всё, что захочу я сам, а не как мне прикажет начальство. Так что завидуй молча! xD

u5er
()
Ответ на: комментарий от GAMer

Если оно станет различным это значит рэйд развалился, а развалился он явно же не от скуки.

anc ★★★★★
()
Ответ на: комментарий от u5er

Вы такое в живую хоть раз видели?

Неа, но когда я первый раз об этому прочитал, то полез копать глубже. И накопал.

И что накопали?

anc ★★★★★
()
Ответ на: комментарий от u5er

Мамкин одмин локалхоста

И горжусь этим! Нет, правда: у меня есть свобода выбора.

«Но в десять ровно мама ждёт тебя домой.»

anc ★★★★★
()

Тред не дочитал, много флейма.

Кто-нибудь смог воспроизвести ошибку? На 2.2.0, на 2.1.х?

Вообще странно, кто-то смог воспроизвести ошибку на 2.1.х и всё равно в changelog пишут

Users running the 2.1.x branch or older are unaffected, as block cloning is a 2.2.x-only feature.

Harliff ★★★★★
()
Последнее исправление: Harliff (всего исправлений: 1)
Ответ на: комментарий от anc

Зачем сжимать?

Чтобы больше поместилось. Прелесть же в том, что я сжимаю не весь диск, а только отдельные директории.

dataman ★★★★
()
Ответ на: комментарий от anc

То, что иноды заканчиваются внезапно. Я думаю, что это из-за того, что в файловых менеджерах и прочих программах выводится информация о свободном месте, а не о свободных инодах.

u5er
()
Ответ на: комментарий от u5er

То, что иноды заканчиваются внезапно.

Вопрос «Что накопали?» подразумевал пруфы, а не сферичное высказывание.

anc ★★★★★
()
Ответ на: комментарий от dotcoder

Ну что ты будешь делать, а говорили профессиональная, энтерпрайз левела, петабайтные хранилища..

MoldAndLimeHoney
() автор топика

Наверно, поэтому я до сих пор пользуюсь ZOL v0.8.6

А кто-нибудь в курсе, онтопик бага присутствует в OpenZFS v2.0.7 ?

Что думаете о таком:

Для надежного хранения в проде IMHO вероятно нужен DRBD поверх разнотипных SDS, размещённых на разных хостах, типа:
		ZFS (Linux и/или Illumos и/или Solaris), Btrfs
			Тогда в случае обнаружения критических багов в тех или иных реализациях SDS,  эти ошибки не повлияют катастрофически на сохранность данных
				Но тогда нужна абсолютная надежность DRBD. Мало того, нужно, чтобы DRBD могла оперативно в realtime показать, что одна из хранилок просирает данные в случае проявления онтопик бага.
		Итого хотя бы: 
			DRBD: 
				Host1: (Linux ZFS v0.8.6  (kernel v.4.19.xxx)  или  Linux ZFS v2.07 (kernel v5.15.xxx)) 
				Host2: Btrfs (kernel v5.15.xxx) 
			наверно сможет обеспечить довольно неплохой уровень надежности хранения и одновременно HA? Если одно из DRBD зеркал начнёт просирать данные или полностью потеряет виртуальное блочное устройство, то данные (и даже uptime) от этого не пострадают, верно? Кроме того нужно обеспечить регулярные реплики каждой части DRBD зеркала на отдельный физический хост (со своим RAM, БП и т.п.)

?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)