Comments 27
Подскажите пожалуйста, моментальное создание снапшотов ведь по-прежнему не защищает от ситуаций, когда во время создания снапшота у нас пишется огромный файл? В снапшот тогда попадёт половинка файла, и при восстановлении снапшота у нас будут битые файлы.

Могу сильно ошибаться, но после записи на диск, записывается чексумма.
Без нее файла не существует. В этом и фишка zfs
Т.е по всем идеям это просто потеря файла, которая выявится при scrub
Другое дело реализоаан ли механизм защиты у zfs, тут нужно копаться в коде или спрашивать разработчиков.

Могу сильно ошибаться, но после записи на диск, записывается чексумма.

В ZFS чексуммы не на файлы, а на блоки. Которые по дефолту — 128кбайт.

вот именно такую вводную статью я и искал когда-то.
сейчас уже неактуально, разобрался, но всё равно спасибо за перевод. я думаю, что он многим будет полезен.

Ностальгия :)
Я использовал ZFS в конце 2000-х на OpenBSD и FreeBSD серверах, тогда это была новинка, но перспективная новинка. Начиная с 8-й версии ZFS поддерживалась ядром ОС и была сильно интереснее чем FFS.
Опыт использования положительный, но надо понимать, что FreeBSD сервера у нас использовались для определенных узкоспециализированных задач.

Пользовался примерно тогда же и до 2016 (когда сменил сферу деятельности). Веб–сервер, файлопомойка и прочее. Очень удобно. Особенно круто было jail–окружения разворачивать из снапшота.

Zfs тут ничем не отличается, для любой ФС ecc память предпочтительней.

Как уже написали выше, проблемы без ECC памяти возникнуть могут на любых ФС, отсутствие ECC не делает 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

По последней ссылке как раз статья-ответ на вашу.
А вот однозначный ответ core разработчика и создателя ZFS news.ycombinator.com/item?id=18480016, решайте сами кому верить.

Миф из вашей ссылки в том, что команда scrub «пересчитывает чексуммы ещё раз и может записать неправильные данные», а по факту scrub никогда не запишет новые данные с новой чексуммой. Всё просто:
— читаем данные и чексумму с диска
— если ОЗУ битая и они не сошлись — пытаемся при наличии другой копии этих данных вычитать их с другого диска
— если, и только если чексумма сойдётся с данными — scrub запишет эту копию вместо «битой» со старой. Но это будет та же чексумма и те же данные
— да, вероятность записи битых данных в таком случае есть, но она аналогична другим ФС. Но шансы сильно больше, что scrub не сможет посчитать чексумму со всех копий данных в пуле и просто переведёт пул в suspended, тем самым обезопасив вас.
— и даже если вам супер повезло и вы записали битые данные и чек сумму, при следующей вычитке проверка не пройдёт и вы об этом узнаете. А на ФС без чексумм вы будете по кругу неограниченное время работать с битыми данными и не знать этого.

Это всё с условием, что вам очень повезло и Ваша ОС работает продолжительное время с битой памятью.
Используя ZFS без ECC можно получить защиту от порчи (смена нуля на единицу и обратно) уже записанных на диск данных, но нельзя быть уверенным в том, что данные не были испорчены за несколько мгновений до этого, пока они находились в оперативной памяти.
То есть ECC RAM защищает данные от непреднамеренного изменения между ZFS и ethernet-кабелем.

Используемая ФС никак не может влиять на то, какие данные в неё записываются. Возможно, что прикладное ПО, которое записывает данные может попробовать повторно прочитать данные и убедиться в том, что она записались правильно, но я такого не встречал.
Интересно, а думают ли они когда нибудь сделать расширяемые vdev? Чтобы можно было добавить диск в raidz(х). А то это такой головняк сейчас…
draid вроде как бы может с таким работать. Но про него тишина, хотя вот на хабре на днях проскакивало его тестирование.
ну или для фанатов raidz с vdev из нескольких dev

нету сравнения с ФС которая у 70% рынка (нтфс) это конечно печалит...

Даже можно посчитать 70% рынка вычислительных устройств. Где смачно превалируют сервера и смартфоны.

NTFS принципиально не отличается от XFS, а вот виндовый VSS Writer ограничен 64 ТБ и это печалит намного больше.

Использую ZFS уже много лет и всем радует, кроме одного: ужасные показатели производительности.
NVMe SSD, выдающий 3 ГБ/с на последовательное чтение на ней способен лишь на 1.2. Со скоростью записи такая же беда.
На HDD тоже ощущается, но не так сильно.
Ем кактус, потому что другие кактусы по набору фич уступают.

Стоит ли сменить UFS на ZFS на медиасерверах под FreeBSD 11, которые используются для хранения в течении месяца и иногда просмотра архивных записей?

Вы получите защиту от бэдблоков, сжатие, что для видео сомнительно, но сильное падение производительности
Решать вам)

Я так понимаю должен быть 3-х кратный запас по пропускной способности при записи на UFS т.к. судя по сообщению habr.com/ru/post/504692/#comment_21686186 единственный недостаток сильное падение производительности :-(
Only those users with full accounts are able to leave comments. Log in, please.