Доступен промежуточный выпуск проекта 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”.
Спасибо, но я лучше на ext4 и LVM посижу.
ну и дурак
corrupts the LV, every time.
I'm having an issue with my LV's becoming corrupted very easily and often. Wondering if anyone else is experiencing this issue while using Arch. Just want to scratch some things off the list such as kernel 5.0 and the newest lvm2. Further Details: smartctl long test passed. no errors in logs outside of what is caused by the corruption and have been resolved Both the EXT4 and NTFS LV's have experienced continuous corruption The corruption is only to content, not to the structure of the LVM in any way. The drive is a 1TB spinning rust There's no reported issues in LVM's git. Corruption only happens during a hard power off of either my PC or one of my VM's. File system doesn't matter, happens to all of them, ext4, ntfs, etc The questions are, Is LVM this fragile for anyone else lately? Is there possibly a setting or a piece of software I should be using to increase reliability? As a note, yes, I am aware you shouldn't hard power off due to the risk of data loss and corruption. However it has become FAR worse and very often to the point of being every time with LVM for me. UPDATE: Clarification. It's not just the host, it's the VM's as well. Hard powering off, "virsh destroy GUEST" corrupts the LV, every time.https://www.reddit.com/r/archlinux/comments/bm2cnw/lvm_easily_corrupted/
Red Hat Enterprise Linux 7.6+ is exposed to corruption where LVM might cause data corruption in the first 128kB of the LVM volumeLVM is prone to write caching vulnerabilities, increasing the likelihood of losing data. The lost data can become very difficult to recover. However, there are specific measures that we can take against this issue.https://www.baeldung.com/linux/logical-volume-management-problems
crypt@witch ~ $ zfs version zfs-2.1.9-FreeBSD_g92e0d9d18 zfs-kmod-2.1.9-FreeBSD_g92e0d9d18 crypt@witch ~ $ freebsd-version 13.2-RELEASE-p5даже не задело. просто не попало в последний релиз FreeBSD.
На 14.0 еще не обновлялся?
это противоречит моей идеи стабильности. обновлю, когда EOL подойдет.
Ясно. Я так и думал. Я тоже так буду делать. Все работает нормально в 13.2-RELEASE, так зачем лезть и наступать на грабли…
да, пусть линуксоиды пока тестируют
Это точно. Или на XFS. Но только без LVM.