LINUX.ORG.RU

Необходимость ECC в самодельном NAS

 , ,


0

3

Србственно, сабж. Вопрос вызван тем, что без ECC выходит гораздо дешевле. Для того, чтобы заиметь ecc, нужно брать хотя бы третью рязань (а 1200 идет без встроенной графики, а без графики потребительские материнки не стартуют. Нужно где-то брать графику). Насколько это важно? Насколько высока вероятность получить bit rot из-за сбоя в памяти?

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

slapin ★★★★★ ()
Ответ на: комментарий от slapin

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

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

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

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

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

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

hateWin ()
Ответ на: комментарий от anonymous

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

hateWin ()

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

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

gag ★★★★★ ()
Ответ на: комментарий от hateWin

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

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

Morin ★★★ ()
Ответ на: комментарий от Morin

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

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

hateWin ()
Ответ на: комментарий от hateWin

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

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

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

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

anonymous ()

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

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

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

NiTr0 ★★★★★ ()

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

zemidius ()
Ответ на: комментарий от hateWin

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от hateWin

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

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

Djanik ()

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

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

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

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

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

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

Legioner ★★★★★ ()
Ответ на: комментарий от NiTr0

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

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

Morin ★★★ ()
Ответ на: комментарий от Morin

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

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

anonymous ()
Ответ на: комментарий от Morin

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

Djanik ()
Ответ на: комментарий от Djanik

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

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

ZFS has no pre-mount consistency checker

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

tool that can repair filesystem damage

zdb

anonymous ()
Ответ на: комментарий от Djanik

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

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

Morin ★★★ ()
Ответ на: комментарий от Legioner

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

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

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

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

anonymous ()
Ответ на: комментарий от Djanik

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

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

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

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

anonymous ()
Ответ на: комментарий от Morin

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

Djanik ()
Ответ на: комментарий от Morin

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

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от Djanik

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от NiTr0

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

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

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

Morin ★★★ ()
Ответ на: комментарий от Morin

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

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

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

aist1 ★★ ()
Ответ на: комментарий от Djanik

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

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

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

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 1)