Избитая тема ECC и NON ECC

Status
Not open for further replies.

alex4573

Cadet
Joined
Apr 30, 2017
Messages
3
Мужики а вам не кажется что ECC это просто развод? Ну надо ведь впаривать мамки и процы кому-то? Ну сами подумайте ZFS использует COW (copy on write), т.е. при перезаписи блока она просто пишет новые "исправленные"(пусть даже некорректные) данные в пул в новый блок данных. При обнаружении большого кол-ва ошибок zfs отправляет в offline диск(и). Мне кажется проблемы могут возникнуть только когда диск почти полон, когда около 100% занято то когда пулу потребуется найти блок для записи типа исправлленых данных он может начать писать в блоки помеченные как свободные. Более того если мы делаем snapshot, то как я понимаю данные snapshot'а в теории не должны подвергаться изменениям. Изменения возможны, только если обнаружены ошибки опять же я думаю коррекция должна производиться используя COW.

COW это отличная методика для работы с данными. Очень часто используется в банках, где операция изменение данных производится через запись новых данных в свободный блок с пометкой о том что старые данные не актуальны. Это необходимо для истории и безопасности сохранности данных. Т.е. в теории даже если у нас начала чудить память ничего страшного произойти не должно, так как система вполне должна быть способна отдать старые snapshot'ы из пула.

Мое видение такое: прогнав память несколько раз используя memtest, не обнаружив ошибок. Я думаю вполне можно обойтись и без ECC. Если делать snapshot'ы и их переиодически бэкапить на другую систему.
Я так и не смог найти подтверждений тому что у людей сыпались массивы. В инете что я видел это ссылки на 4 случая и все. В одном случае у человека memtest в течении одной проверки выявил 2 ошибки с памятью. В моем случае сколько бы часов я не гонял мой комп и лаптоп я так и не видел ошибок.
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
Ты не прав. ZFS весь построен на утверждении что метаданные всегда корректны. По этой причине там нет обычного fsck. Scrub -- это никоим образом не fsck. Он только проверяет что данные читаются, но никак не контпролирует их корректность. Если из-за взбрыкнувшей памяти ты получиш битые метаданные записанные на диск, то ты можеш этот пул вообще больше не импортировать.

У меня у самого есть знакомый сервер с не-ECC памятью -- ну нет у украинского университета денег на нормальное железо. За последние несколько лет всего только 2-3 раза огребал битые контрольные суммы данных (на всех дисках сразу), из-за чего приходилось поднимать соответствующие файлы из бакапа. Метаданные слава богу пока не страдали. Но там где объем данных измеряется сотнями терабайт и петабайтами, подъем из бакапа может занять неделю-другую, а это уже серьезно.
 

Lordbl4

Dabbler
Joined
Jul 4, 2016
Messages
42
Мужики а вам не кажется что ECC это просто развод?
"механика" работы ZFS завязана на работе с памятью, ошибки в памяти = ошибки в контрольных суммах = ошибки в данных

Я думаю вполне можно обойтись и без ECC. Если делать snapshot'ы и их переиодически бэкапить на другую систему.
Как уже писал оратор в посте выше - если объёмы данных не столь велики и восстанавливаются с минимальным даунтаймом или же сам даунтайм не сыграет роли - то 2 хранилища под управлением freenas и без ECC вполне себе справятся с задачей.

COW скорее фича, чем решение проблемы отсутствия ECC, ровно как и контроль ошибок памяти внутри самой памяти а не сторонними средствами, типа мемтеста. За удобство приходится платить - материнка с поддержкой ECC + сама память.
 

chs

Guru
Joined
Apr 18, 2017
Messages
500
"всё дело в цене на билет". Мы же тратим дисковое пространство на всякие RAID уровня больше нуля. Это плата за надёжность дисков. Тоже самое и с ЕСС. Если нужна ещё большая надёжность и быстрота восстановления будешь зеркалировать и СХД (что уже есть у NetApp).
В моей практике, ошибок, связанных с NonECC памятью (чтоб можно было однозначно об этом сказать) не было. Но это не означает, что на хост с критическими данными я поставлю обычный комп с NonECC памятью.
 

alex4573

Cadet
Joined
Apr 30, 2017
Messages
3
Дантайм не важен. Важно низкое потребление электроэнергии.

В общем что очень хочется купить вот эту мамку https://www.aliexpress.com/item/HCI...lgo_pvid=6b5a4118-30e0-41f7-856a-4ccf57dff185

Довольно хорошая мамка для NAS. Она просто супер. 10Вт потребляемая мощность. 13 портов SATA. Хочу на ней поставить Hyper-v. На этом Hyper-v сделать 1 машину с pfsense, вторую машину это Ubuntu для хранения данных типа NAS, ZFS и все дела.
В общем это все для домашнего пользования, что бы было доступно 24/7 и не жрало много энергии. pfsense хочу что бы иметь понимание и контроль чем сын занимается в инете. Мне эта мама нравится тем что она без кулера. Я хочу без двигающихся деталей. Все мамки которые ECC они все для мощных процов. Мне большая производительность не нужна. Мне надо низкое потребление лектричества,
Ибо дорогое оно у нас.

Я не собираюсь расчитывать только на один ZFS, по след причинам:
1) человеческий фактор(имел опыт пересоздания массива с потерей данных)
2) пожар
3) кража
4) возможные баги самого ZFS
5) ошибки памяти
Глядя на первые 4 проблемы, начинаешь думать что просто нет смысла городить дорогую систему.

Помимо ZFS собираюсь делать копии важного на blu ray диски и просто копии на обычные винты на случай если что случится с ZFS.

От ZFS мне только надо:
1) deduplication
2) snapshotы
3) восстановление данных так как собираюсь использовать зеркала.

Как таковых данных у меня не много. В основном это просто фотографии и видео примерно 1.3 Tb. В целом не более 3 Tb. Т.е. мне хватит mirror из 2*3Tb. Это не значит что мне хватит 2 SATA порта. Мне хочется что бы другие винты с менее важным барахлом были подключены и спали. Если понадобятся то расбудить их.

Вообще мне очень интересно как происходит resilvering mirror при следующей ситуации: создано зеркало, записано много данных. Один винт отключается. В degraded state я записываю еще 5 небольших файлов. Подключаю винт из зеркала хочу что бы можно было выполнить 1 и/или 2
1) что бы на второй винт были скопированы только 5 файлов, вместо полного копирования
2) Если обнаружены bad сектора на обоих винтах(предположим нету пересечения по bad секторам) то можно было бы восстановить хотя бы данные которые имеются на обоих винтах.
 
Last edited:

alex4573

Cadet
Joined
Apr 30, 2017
Messages
3
Ты не прав. ZFS весь построен на утверждении что метаданные всегда корректны. По этой причине там нет обычного fsck. Scrub -- это никоим образом не fsck. Он только проверяет что данные читаются, но никак не контпролирует их корректность.
Помоему ты очень ошибаешься. Во первых zfs хранить hash на каждый блок данных и не важно что это за данные это могут быть как пользовательские данные так и мета данные. ZFS практически не делает различия между пользовательскими данными или метаданными. Есть отличие в том что метаданные хранятся в 2 или 3 копиях в зависимости от типа метаданных.

Вот здесь
https://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
4.1.1 Basic structures Block pointers: A block pointer is the basic structure in ZFS for addressing a block on disk. It provides a generic mechanism to keep parental checksums and replicas of on-disk blocks. Figure 1 shows the block pointer used by ZFS. As shown, the block pointer contains up to three block addresses, called DVAs (data virtual addresses), each pointing to a different block having the same contents. These are referred to as ditto blocks. The number of DVAs varies depending on the importance of the block. The current policy in ZFS is that there is one DVA for user data, two DVAs for file system metadata, and three DVAs for global metadata across all file system instances in the pool [39]



Кому интересно могут глянуть сюда https://github.com/openzfs/openzfs/...c829e9a2/usr/src/uts/common/fs/zfs/dsl_scan.c
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
Во первых zfs хранить hash на каждый блок данных и не важно что это за данные это могут быть как пользовательские данные так и мета данные. ZFS практически не делает различия между пользовательскими данными или метаданными. Есть отличие в том что метаданные хранятся в 2 или 3 копиях в зависимости от типа метаданных.

Да, это так, контрольные суммы и множественные копии там есть. Но если ошибка возникла в памяти до или во время подсчета контрольной суммы, то или контрольная сумма будет верной при по сути поврежденных данных, что добром не закончится, либо контрольная сумма не совпадет для всех 2-3 копий, что тоже не многим лучше.
 

Lordbl4

Dabbler
Joined
Jul 4, 2016
Messages
42
Дантайм не важен. Важно низкое потребление электроэнергии.
Из разряда: "не нужно мне - не нужно никому" :D
В таком случае вам следовало бы подробнее описать вашу конкретную цель в первом посте, вместо поднятия холивара.

Как говорил небезызвестный человек из команды фринас - в случае без ECC памяти вопрос "развалится ли пулл?" принимает форму "когда развалится пулл, то..."

Зачем вообще обсуждать избитую проблему? Резервирование данных дешевле - собираем из палок и изоленты NAS и бэкапим куданибудь. Собрать платформу с ECC выгоднее - собираем и всё равно бэкапим, на те же палки с изолентой, хотя бы.

Добавлю, у вас цель - небольшой SOHO NAS, но вы смотрите в сторону более энтерпрайзного решения, которое требует значительно больше ресурсов (сама технология ZFS и система в целом) чем аналогичные по функционалу собратья ;)
 
Status
Not open for further replies.
Top