Comments 33
Спасибо, интересно, жду продолжения.
а что вы хотите получить?
Могу сильно ошибаться, но после записи на диск, записывается чексумма.
Без нее файла не существует. В этом и фишка zfs
Т.е по всем идеям это просто потеря файла, которая выявится при scrub
Другое дело реализоаан ли механизм защиты у zfs, тут нужно копаться в коде или спрашивать разработчиков.
вот именно такую вводную статью я и искал когда-то.
сейчас уже неактуально, разобрался, но всё равно спасибо за перевод. я думаю, что он многим будет полезен.
Я использовал ZFS в конце 2000-х на OpenBSD и FreeBSD серверах, тогда это была новинка, но перспективная новинка. Начиная с 8-й версии ZFS поддерживалась ядром ОС и была сильно интереснее чем FFS.
Опыт использования положительный, но надо понимать, что FreeBSD сервера у нас использовались для определенных узкоспециализированных задач.
А если нет ECC, стоит использовать ZFS или btrfs?
Или что-то другое?
Zfs тут ничем не отличается, для любой ФС ecc память предпочтительней.
https://www.ixsystems.com/community/threads/ecc-vs-non-ecc-ram-and-zfs.15449/
Вот описание уровня проблем, которые возникнут с zfs и с другими файловыми системами.
Цены на восстановление вовсе не радуют.
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM.arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271
So what does your evil RAM need to do in order to actually overwrite your good data with corrupt data during a scrub? Well, first it needs to flip some bits during the initial read of every block that it wants to corrupt. Then, on the second read of a copy of the block from parity or redundancy, it needs to not only flip bits, it needs to flip them in such a way that you get a hash collision. In other words, random bit-flipping won’t do – you need some bit flipping in the data (with or without some more bit-flipping in the checksum) that adds up to the corrupt data correctly hashing to the value in the checksum. By default, ZFS uses 256-bit SHA validation hashes, which means that a single bit-flip has a 1 in 2^256 chance of giving you a corrupt block which now matches its checksum. To be fair, we’re using evil RAM here, so it’s probably going to do lots of experimenting, and it will try flipping bits in both the data and the checksum itself, and it will do so multiple times for any single block. However, that’s multiple 1 in 2^256 (aka roughly 1 in 10^77) chances, which still makes it vanishingly unlikely to actually happen… and if your RAM is that damn evil, it’s going to kill your data whether you’re using ZFS or not.jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data
По последней ссылке как раз статья-ответ на вашу.
Миф из вашей ссылки в том, что команда scrub «пересчитывает чексуммы ещё раз и может записать неправильные данные», а по факту scrub никогда не запишет новые данные с новой чексуммой. Всё просто:
— читаем данные и чексумму с диска
— если ОЗУ битая и они не сошлись — пытаемся при наличии другой копии этих данных вычитать их с другого диска
— если, и только если чексумма сойдётся с данными — scrub запишет эту копию вместо «битой» со старой. Но это будет та же чексумма и те же данные
— да, вероятность записи битых данных в таком случае есть, но она аналогична другим ФС. Но шансы сильно больше, что scrub не сможет посчитать чексумму со всех копий данных в пуле и просто переведёт пул в suspended, тем самым обезопасив вас.
— и даже если вам супер повезло и вы записали битые данные и чек сумму, при следующей вычитке проверка не пройдёт и вы об этом узнаете. А на ФС без чексумм вы будете по кругу неограниченное время работать с битыми данными и не знать этого.
Это всё с условием, что вам очень повезло и Ваша ОС работает продолжительное время с битой памятью.
То есть ECC RAM защищает данные от непреднамеренного изменения между ZFS и ethernet-кабелем.
Используемая ФС никак не может влиять на то, какие данные в неё записываются. Возможно, что прикладное ПО, которое записывает данные может попробовать повторно прочитать данные и убедиться в том, что она записались правильно, но я такого не встречал.
отличная статья
такие бы ещё про btrfs и про bcachefs
нету сравнения с ФС которая у 70% рынка (нтфс) это конечно печалит...
Использую ZFS уже много лет и всем радует, кроме одного: ужасные показатели производительности.
NVMe SSD, выдающий 3 ГБ/с на последовательное чтение на ней способен лишь на 1.2. Со скоростью записи такая же беда.
На HDD тоже ощущается, но не так сильно.
Ем кактус, потому что другие кактусы по набору фич уступают.
Вы получите защиту от бэдблоков, сжатие, что для видео сомнительно, но сильное падение производительности
Решать вам)
Никто не делает сначала vdev
разве?
Интересно, насколько это правильно, неправильно или это всё равно с точки зрения топологии ZFS?
в случае искажения данных в одной копии zfs «увидит» это и попытается считать вторую копию. обычное зеркало так не умеет.
разве?
Ну, условно) Я тут решил заняться NASостроительством и посмотрел с десяток блогов, посмотрел как TrueNAS пул создаёт и сложилось такое впечатление — vdev мало где вообще рассматривается и народ пул создаёт типа «zpool create my-pool mirror /dev/sda /dev/sdb». Я понимаю что это статьи для новичков и все такое, но встал вопрос «а как правильно», если у меня всего два одинаковых носителя. Целостность при чтении же всё равно контролируется. Если периодически запускать scrubbing, то ошибки будут восстанавливаться если хоть где-то будет живая копия.
В поисках понятного объяснения работы ZFS набрел на эту тему.
ARC — гораздо менее наивный алгоритм, который можно рассматривать как «взвешенный» кэш. После каждого считывании кэшированного блока он становится немного «тяжелее» и его становится труднее вытеснить — и даже после вытеснения блок отслеживается в течение определённого периода времени.
Это многое объясняет когда игрался с ZFS и не мог понять, почему на подключенный к ZFS диск кэша пишутся данные не сразу все, а определенными частями при каждом чтении тех же самых данных.
Основы ZFS: система хранения и производительность