А памяти то сколько? И насколько важный NAS? Чем рискуешь если прочитанное в память там незаметно повредится и будет записано на диск уже поврежденным? И не будет ли это результатом сбоя фирмвари черепичного диска или его кеша? Просто если делать важный NAS - память там не самое дорогое.

Если нет ECC в каждом клиенте с правом записи на шары, то сам догадайся, насколько оно ценно.

И насколько важный NAS? Чем рискуешь если прочитанное в память там незаметно повредится и будет записано на диск уже поврежденным?

Как минимум – бэкапы важной инфы. Вообще, хочется перенести туда хотя бы личный фотоархив. Это ценная информация для меня.

А памяти то сколько?

Хочу попробовать zfs. Для нее надо бы гигов 8.

И не будет ли это результатом сбоя фирмвари черепичного диска или его кеша?

Ненавижу и стремлюсь уничтожить :) Буду выбирать диски без этого дерьма.

ECC это про HA, а не про то что вы тут сверху ответили

Логично. Но у клиентов аптайм несколько часов, а у сервера – несколько месяцев. И если перенести всю информацию на сервер?

И на десктопе дисковый кеш не будет сипользоваться так активно. А на файловом сервере эти данные все время висят в кеше, к ним постоянно обращаются, сервер перезагружается редко.

Для того, чтобы заиметь ecc, нужно брать хотя бы третью рязань

У меня на Athlon64 3000+ где-то с 2006-го было включено ECC на ASUS и стояли ECC планки.

NAS это файло хранилище на носителях, если у тебя он хранит данные в опере, то ты делаешь что-то не так

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

NAS это файло хранилище на носителях, если у тебя он хранит данные в опере, то ты делаешь что-то не так

Почему? Если данные используются часто, они кешируются в оперативке, разве нет?

вопрос выбора стратегии, реши ее для себя. либо надежно хранить, либо быстро читать

И на десктопе дисковый кеш не будет сипользоваться так активно.

Ну вообще будет.

А на файловом сервере эти данные все время висят в кеше, к ним постоянно обращаются, сервер перезагружается редко.

В типичном домашнем NAS 32-64 Гб памяти против десятков Тб говна на дисках, волатильность кэша высокая. Да и пишутся данные не из кэша чтения, а через буферы записи.

В типичном домашнем NAS 32-64 Гб памяти против десятков Тб говна на дисках

Лови путешественника во времени!

Добро пожаловать в адбудующее:

https://www.reddit.com/r/homelab/

https://www.reddit.com/r/DataHoarder/

Это, мягко говоря, не типичные nas.

Пожалуй :)

ЕСС есть даже на атлонах.

и без графики потреительские материнки стартуют на ура.

учитывая, что кеш writeback - вероятнотсь получить порченную ФС или порченное содержимое файла совсем не нулевая.

HA к ЕСС не имеет никакого отношения. ЕСС - это именно про сохранность и целостность данных.

classic

как обычно, люди компенсируют маленький детодельный орган мощными железками и тачками:)

https://en.wikichip.org/wiki/amd/athlon/200ge

Здесь пишут, что ECC нет.

Всё зависит от важности данных. Есть потерей нескольких фотографий из домашнего архива можно пренебречь - можно обойтись без ECC. Но я бы рекомендовал использовать ECC.

ЕСС есть но АМД не гарантирует ее работу. но специально в кристалле не зарезала. во всяком случае в 2200G ЕСС точно присутствует, и вроде как в атлонах тоже есть.

zfs

она какая-то сложная для понимания: какие-то пулы, датасеты, куча настроек. ее нет в ядре линукса. нужно или патченное ядро либо через dkms ставить. попробуй лучше btrfs

ее нет в ядре линукса

Хочу попробовать FreeBSD.

Хочу попробовать zfs

В отличие от других фс, zfs считает и пишет контрольные суммы данных и метаданных, если данные испортились в памяти перед записью, то никто это не заметит и запишут как есть. Плюс нет средств проверки консистенстности фс перед монтированием и инструментария восстановления (ZFS has no pre-mount consistency checker or tool that can repair filesystem damage.) Короче пишут, что без ecc все кончится плохо (complete loss of the storage).

А чего бы не взять бу и/или хуанань с зеоном? Если это именно нас-хранилка, то современное железо там как бы и не особенно нужно.

ECC длЯ файло-помойки? Забей!

Насколько это важно?

Если <= 16 GB оперативной памяти, то не очень важно. Если больше, то желательно.

Насколько высока вероятность получить bit rot из-за сбоя в памяти?

Для типового домашнего NAS, думаю, меньше процента за год.

В общем ECC иметь хорошо, но не критично. Если выходит гораздо дешевле без него, то не заморачивайся. Можешь использовать ФС с хранением контрольных сумм, это не панацея, но теоретически в некоторых случаях может помочь.

PS bit rot не существует, проблемы от отсутствия ECC будут при записи данных на диск, а не при хранении данных на диске. При хранении данных все диски хранят контрольные суммы и если бит «сгниёт», то при чтении сектора вернётся ошибка, незаметным это не останется. Для борьбы с этим используется избыточный рейд или бэкапы.

ФС с хранением контрольных сумм

Например?

ZFS, BtrFS

нахрена данные файлопомойки держать в озу? нахрена? в данном контексте использование ECC даст только HA. это помойка, ты никак не будешь обрабатывать данные на ней. блин ну хоть немножко теории читайте.

совсем для наглядности, забрали данные с наса на рабочую станцию, а там внезапно обычная память - так понятно? что запишем битое обратно понятно?

ECC это про HA, а не про то что вы тут сверху ответили

тебе уже неоднократно говорили не лезть в темы, в которых ты не алё. так вот ещё раз скажу

Если клиент пишет испорченные данные, это проблема клиента. А complete loss of the storage - это проблема наса. Это понятно? И zfs будет работать плохо на дешевом консъюмерском железе. Если включить дедупликацию, то 8 гиг это просто ни о чем. И не надо использовать freebsd или линукс. Даже старая солярка от Oracle будет работать лучше. Просто надо прочитать гайды по тюнингу файловой системы и ос, написанные специалистами.

печка

если данные испортились в памяти перед записью, то никто это не заметит и запишут как есть.

и zfs тут при том, что…?

ZFS has no pre-mount consistency checker

лол, эксперты в треде

tool that can repair filesystem damage

zdb

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

увы в мирном секторе резервирование только такое

Для типового домашнего NAS, думаю, меньше процента за год.

тебе лучше вообще не думать, по крайней мере не делиться результатами этой деятельности на техническом форуме

bit rot не существует

а ещё лучше забаниться и сделать вдоль

zdb, performs basic consistency checks on the pool and associated datasets, and report any problems detected

сказать-то что хотел?

repair filesystem damage она не могет, и никто не могет, кроме специалистов

она не могет, и никто не могет

всё оно могёт, голову нужно просто хоть иногда включать

кроме специалистов

понятное дело, что рандомный красноглазик с лора на такое в принципе не способен

Речь о том, что опытные люди говорят о потере всех данных при работе на памяти без ecc. Чем плоха ext4 для домашнего нас? Она не требует много памяти, ошибки умеет исправлять перед монтированием.

zdb(1M)

Покажи в каком месте написано про исправление ошибок?

для вас будет наверное огромным открытием, что линукс держит кучу всего (в т.ч. структуры файловой системы) в кеше, в оперативной памяти. и что данные на диск сбрасываются аж никак не мгновенно. более того - даже если сделать каким-то образом кеш write-through, это нифига не спасет - просто потому, что при изменении ФС блок со служебными структурами не будет подчитываться с блинов, а будет браться из кеша, из памяти. т.е. потенциально битый, если нет ЕСС. после чего в него вносятся правки, и поврежденный блок сохраняется на блины. на выходе - разломанная ФС.

так что давайте расскажите еще про ненужность ЕСС на файлохранилище :)

ну ок, внесли вы правки в ФС, да только из-за флапа битов оказалось что файл начинается не с 123456 блока, а с 23572548. как вам, сильно полегчает от того что fsck это выявит и объявит что «все пропало, файл умер»?

ну вот такие хранилища ныне делают, вообще это забавно особенно для сохо сегмента, железо убогое, а программная реализация, мягко скажем убогая. нет, не сюрприз увы

хомячий нас имеется, жив здоров почти десяток лет, да на нем нет есс, впрочем ничего экзотического вроде zraid там тоже нет

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

для nas хватит просто целерона, нафига тебе ECC ? - купи лучше топовый synology

/me очень сожалеет что не может поставить лайк. Очень грамотно и толково сказал. Кратко и точно.

Одно дело, что ошибка памяти может произойти, а другое дело — чтобы она что-то реально зааффектила. Вот есть говно-NAS и на нем лежат мои говно-фоточки. И вот где-то бит флипнулся и попал на диск. С очень высокой вероятностью он флипнется где-нибудь в pixel data, и я про это никогда не узнаю вообще.

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

Вопрос не в том, cтавить ECC или не ставить. А вопрос в том, куда его ставить и на какие задачи. Ставить ECC в материнки потребительского класса особого смысла нет, так как они не предназначаются для серверных задач. Они для того, чтобы в интернете шариться, видосики смотреть, почту читать и в игры играть.

Даже старая солярка от Oracle будет работать лучше.

На чём лучше? На современном железе она вряд ли запустится.

Чем плоха ext4 для домашнего нас? Она не требует много памяти, ошибки умеет исправлять перед монтированием.

ZFS исправляет ошибки в метаданных путём отката к предыдущей подтверждённой завершённой транзакции. Если пул повреждён и не монтируется автоматом, то можно попробовать дать команду zpool import -F poolname.

ZFS очень экономично расходует оперативную память, если её реально мало и не используется дедупликация.