Есть ли преимущество в том, что у меня есть NAS с ECC-памятью и файловой системой ZFS, когда я работаю с системами без них?

ZFS довольно требовательна к тому, на каком оборудовании она работает.

Не в том смысле, что у вас должен быть абсолютно правильный набор микросхем, видеокарта, версия прошивки диска и т. Д., А в смысле возможностей, предоставляемых аппаратным обеспечением. Помните, ZFS была разработана как серверное решение высокого класса, и некоторые допущения, которые она делает, отражают это.

Основная часть того, что делает ZFS настолько отличным средством хранения данных, о котором вы заботитесь, заключается в том, что вы можете настроить его таким образом, чтобы как обнаруживать, так и исправлять ошибки в хранилище. Это могут быть тривиальные ошибки, такие как однократный переворот, или катастрофические ошибки, например, сбой нескольких дисков одновременно. До тех пор, пока вы превышаете пороговое значение избыточности вашего хранилища (например, не более двух дисков одновременно испытывают проблемы в raidz2 vdev), ZFS может исправить любую ошибку, используя избыточные данные. Дальнейшие ошибки, в зависимости от того, где и как они возникают, могут привести к (полу) изящной системной панике или простой ошибке ввода-вывода.

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

Однако это величие зависит от того факта, что оперативной памяти можно доверять. Вся эта проверка, исправление, переписывание и так далее происходит в основном в оперативной памяти. На высокопроизводительных серверах вы не найдете ничего, кроме ECC RAM.

ZFS защищает (и обрабатывает) метаданные пула, метаданные файловой системы и пользовательские данные одинаково. Здесь нет никакой разницы.

Если ваша рабочая станция испытывает переворот в битах ОЗУ, то когда вы записываете битовые данные в ZFS, битовые данные будут основой для того, что ZFS в конечном итоге записывает на диск. Это, очевидно, плохо, потому что это означает, что ваш файл будет поврежден. Тем не менее, битовые данные будут правильными в отношении ZFS. Это на самом деле хорошо, потому что это означает, что все нормальные методы восстановления ZFS будут работать. Да, самая последняя копия рассматриваемого файла будет повреждена, но она все равно будет повреждена, независимо от того, какую файловую систему вы использовали. Вы можете использовать моментальные снимки ZFS, чтобы, по крайней мере, вернуться в исходное состояние к нетленной копии. Установите что-то вроде zfs-auto-snap, чтобы снимать ваши файловые системы через регулярные, короткие интервалы, сохранять более грубую историю в обратном направлении и забывать об этом до тех пор, пока они вам не понадобятся. (Например, сохраняйте десять снимков с интервалом в десять минут; 50 снимков с интервалом в один час; 30 снимков с интервалом в шесть часов и т. Д.) Снимки практически бесплатны в ZFS; если вы используете ZFS, используйте также снимки.

Если ваш сервер хранения данных, на котором работает ZFS, испытывает проблемы с ОЗУ, будь то перевёрнутый бит или зависание (один или несколько) битов, и у вас есть ECC RAM на сервере хранения, это будет обнаружено, и событие будет зарегистрировано, или система будет быть остановленным (если ошибка не может быть исправлена). В любом случае, целостность данных, хранящихся на сервере, сохраняется. Если ваш сервер хранения ZFS имеет оперативную память не-ECC, то ошибка может распространяться по всем вашим данным и метаданным, поскольку ZFS пытается "исправить" ошибки, которые на самом деле являются лишь плодом воображения компьютера. В худшем случае, который действительно случается с людьми, весь ваш пул будет разрушен из-за этого, и все ваши данные будут удалены. Резервирование уровня хранения / уровня vdev здесь тоже не поможет. В большинстве других файловых систем (без функции автокоррекции) будет повреждено только одно место, на которое непосредственно повлиял переворот, и если это произойдет с метаданными файловой системы, то их легко исправить с помощью традиционных средств проверки файловой системы и восстановления. инструменты. ZFS не имеет этого аварийного люка; fsck.zfs нет. (Существует zpool scrub, но он не работает, если пул не работает).

Что я не смог найти в Google, так это: какой смысл иметь максимально надежный хостинг файлов NAS (или в качестве резервной копии), когда я работаю с файлами на менее надежных компьютерах?

Это означает, что у вас есть надежное хранилище данных. Вы знаете, что как только данные попадут на ваш NAS, они будут защищены от повреждения. Любое повреждение либо будет устранено автоматически, либо вы будете проинформированы о проблеме (в случае ZFS - из-за ошибки ввода-вывода). Данные могут все еще быть повреждены, пока они работают с использованием менее надежных систем, но у вас будет возможность найти известную не поврежденную копию. Это является преимуществом, даже если только система NAS имеет ECC RAM, ZFS и высококачественные системы мониторинга и оповещения.

Затем вы можете, при желании, добавить (в частности) ECC RAM к другим системам, если позволяет ваш бюджет, чтобы закрыть последнюю дыру.

Нужно ли (образно) выбрасывать мои текущие системы и заменять их (мини) серверным оборудованием, если я не хочу беспокоиться о гниении и т. Д.? И если я пойду по этому пути, могу ли я разумно ожидать, что у меня будут ресурсы для чего-то кроме запуска ZFS? Не тратя тысячи долларов?

Во-первых, вам не нужно аппаратное обеспечение серверного уровня. В первую очередь вам требуется ОЗУ ECC (и контроллер / чипсет ЦП и памяти, поддерживающий ОЗУ ECC), достаточно надежное постоянное хранилище и, в идеале, чехол, позволяющий легко добавлять и удалять диски во время работы системы. Это не должно быть очень дорого, и, конечно, не должно стоить "тысячи долларов".

Во-вторых, ZFS любит оперативную память, но в основном для кэширования. При большинстве рабочих нагрузок 8–16 ГБ ОЗУ должно быть вполне достаточно, а 24–32 ГБ (легко достижимо даже с "потребительскими" материнскими платами) по-прежнему по разумным ценам даже при покупке высококачественной ОЗУ ECC под маркой. ZFS не сильно жаден до процессора; Вы можете сделать так, чтобы ему потребовалось много ресурсов ЦП (как в случае с ZoL, путем настройки sha256, сжатия gzip-9 и, возможно, дедупликации в комбинации), но это не обязательно. Моя собственная система работает на ZFS, но не слишком мощная (процессор FX-6100 отключен), я использую sha256 везде, и даже при чисто последовательном вводе / выводе диски являются ограничивающим фактором: как только он проходит начальный часть скраба, считываемая случайным образом, на скрабах у меня примерно такая же пропускная способность, как на сыром dd с базового устройства хранения, с процессором, чтобы сэкономить.

Что я не смог найти в Google, так это: какой смысл иметь максимально надежный хостинг файлов NAS (или в качестве резервной копии), когда я работаю с файлами на менее надежных компьютерах?

Вероятность того, что что-то пойдет не так, накапливается.

Другими словами (и с поддельными номерами):
Если есть вероятность 10% что-то пойдет не так на NAS, и
Если есть вероятность 10% что-то пойдет не так на другом устройстве,
Тогда у вас будет 20% вероятность сбоя при чтении чего-либо из NAS и воспроизведении этого на другом устройстве.

Я также не могу найти хорошую информацию по исправлению ошибок в Samba

Какая версия самбы. Протоколы немного изменились между тремя версиями.

если это вообще подвержено ошибкам, то почти все остальное бессмысленно (если я лично не хеширую все и проверяю все передачи).

Всегда есть риск ошибок. Это просто происходит. И они действительно обнаруживаются и исправляются (например, с помощью контрольных сумм). Это не всегда верно при использовании ОЗУ, что можно улучшить с помощью контроля четности и / или ECC. Однако эти проблемы относительно маловероятны, и вам нужно найти баланс между позолоченным (и дорогим) дизайном и "достаточно хорошим".

Этот баланс будет совсем другим для некоторых из нас (например, банкам нужны вещи совершенно). Они, вероятно, не гарантируют использование ECC в личных системах, предназначенных для воспроизведения фильмов.