Планируется ли поддержка ядра 6.6, которое новое LTS? @gmelikov

Планируется ли поддержка ядра 6.6, которое новое LTS? @gmelikov

хз что в коммитах, я юзаю пакеты gentoo, а туда попадают только релизы :)

Ну и типа, это значит что скоро будет релиз 2.2.1 ?

при импорте была ошибка

Мдас. А только вчера мне втирали, что импорт безопасен....

либо пул повредился ещё при придыдущей версии, хотя scrub делал

Выше есть

WARNING: zfs: adding existent segment to range tree (offset=a18422c6000 size=4a000) ZFS: Unloaded module v2.2.0-1_g459c99ff2 ZFS: Loaded module v2.2.1-1, ZFS pool version 5000, ZFS filesystem version 5 PANIC: zfs: adding existent segment to range tree (offset=a18422c6000 size=4a000) Showing stack for process 4052008 CPU: 27 PID: 4052008 Comm: z_wr_iss Tainted: P OE 6.5.11-300.fc39.x86_64 #1 Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.6a 09/27/2023 Call Trace: <TASK> dump_stack_lvl+0x47/0x60 vcmn_err+0xdf/0x120 [spl] zfs_panic_recover+0x79/0xa0 [zfs] range_tree_add_impl+0x28f/0xea0 [zfs] ? range_tree_remove_impl+0x55d/0xf50 [zfs] space_map_load_callback+0x59/0x90 [zfs] space_map_iterate+0x195/0x410 [zfs] ? __pfx_space_map_load_callback+0x10/0x10 [zfs] space_map_load_length+0x7f/0x100 [zfs] metaslab_load+0x184/0x9d0 [zfs] ? __kmem_cache_alloc_node+0x19d/0x340 ? spl_kmem_alloc+0x116/0x130 [spl] metaslab_activate+0x3b/0x280 [zfs] ? metaslab_set_selected_txg+0x94/0xd0 [zfs] metaslab_alloc_dva+0x64f/0x12d0 [zfs] metaslab_alloc+0xe2/0x290 [zfs] zio_dva_allocate+0xc4/0x8d0 [zfs] ? kmem_cache_free+0x22/0x3a0 ? zio_io_to_allocate+0x63/0x90 [zfs] zio_execute+0x84/0x120 [zfs] taskq_thread+0x2c0/0x4e0 [spl] ? __pfx_default_wake_function+0x10/0x10 ? __pfx_zio_execute+0x10/0x10 [zfs] ? __pfx_taskq_thread+0x10/0x10 [spl] kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>

?

Да, как раз твои и Ивана сообщения

> disables block cloning by default я так понимаю, погнута новая для zfs фича, которая reflink Юзал её на xfs. Задумка хорошая, но реализация не очень понравилась. Был удивлен, что затащили её в zfs. И вот...

Зато в btrfs эта фича работает ЗБС :)

Мдас. А только вчера мне втирали, что импорт безопасен....

Релизнули 2.2.1 , важно Note: We recommend that anyone running zfs-2.2.0 to please update to this release. Gentoo users have identified a block cloning bug (#15526) that can result in data corruption in zfs-2.2.0. To workaround this, zfs-2.2.1 disables block cloning by default (see #15529 and 479dca5).

в проксмоксе её по дефолту отключили, как знали.

там уже есть 2.2.0 или речь про эту фичу?

❓Вопрос знатокам Как ведет себя zfs, если не весь диск неисправен, а обнаружена неустранимая ошибка только в одном блоке? Как-то помечается один из файлов как поврежденный, или же сразу весь пул херется?

Это пока теоретический вопрос. Например, появился единственный не читаемый сектор на диске в страйп-пуле. Но более для меня актуальный - допустим, в пуле raidz1 при скрабе или ресилверинге не удается исправить единственную ошибку в одном байте каком-то. Не приведет ли это к потере всего пула?

Ну, допустим, в страйп-пуле - ошибка ДИСКА. Блок, сектор - разве настолько важно? Если разное поведение - то в идеале ответ предполагал бы, что "в таком случае - так, в другом - вот так".

С УМЕР - все понятно, это описано в документации. А если не умер, а ошибка в единственном месте (блоке, секторе, файле)? Считается ли при этом, что ВЕСЬ ДИСК умер или по-другому обрабатывается?

Планируется ли поддержка ядра 6.6, которое новое LTS? @gmelikov

Это пока теоретический вопрос. Например, появился единственный не читаемый сектор на диске в страйп-пуле. Но более для меня актуальный - допустим, в пуле raidz1 при скрабе или ресилверинге не удается исправить единственную ошибку в одном байте каком-то. Не приведет ли это к потере всего пула?

6.6 завезли если что

Давайте попробую конкретизировать.

Есть пул raidz1, на котором проходил ресилверинг одного диска. По неизвестной причине вдруг другой диск перешел в статус REMOVED. После перегрузки этот диск появился снова и начался ресилверинг на нем. Вот вдруг в процессе ресилверинга этих уже двух дисков будет обнаружена ошибка в единственном месте, которую избыточность этого пула не может исправить. Допустим, это место относится к единственному байту единственного файла. Будет ли как-то помечен только этот файл как неисправный, или же zfs решит, что появилось два неисправных диска в пуле с избыточностью 1 и на основании этого весь пул признает негодным?

Я описал Вам ситуацию. И то и другое возможно

То есть возможно, что вместо потери одного пиксела на какой-то фотке zfs уничтожит весь архив фото, например?

Как то, что диск данные в этом секторе будут признаны мёртвыми и восстановление будет невозможно, если встроенная CRC не справится, так и вариант, то встроенная CRC диска справится сама По этой причине существует scrub, по этой причине существует SMART, по этой причине существует Raid-6 (z2)

встроенная (в ZFS) "CRC" (там не тлько CRC может быть) исправлением ошибок не занимается :)

Я про CRC уровня диска

ZFS тут как бэ не причём

Ну ЦРЦ в целом не занмиается исправением ошибок всё же. Конечно тут можно сказать что BCH это по сути большущее CRC, но всё же там алгоритм исправления нетривиальный )

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

Ну ЦРЦ в целом не занмиается исправением ошибок всё же. Конечно тут можно сказать что BCH это по сути большущее CRC, но всё же там алгоритм исправления нетривиальный )

Я думаю это тот самый случай когда нужно проверить. записать файл с известной последовательностью байт (отключив упаковку), потом найти её на диске и испортить, и посмотреть что ZFS сделает

Потому что для меня CRC в первую очередь cyclic redundancy code, а не cyclic redundancy check

https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf например. "used for error *detection*"

ну вощем это не общий случай рид-соломона обзывать CRC