Ivan
кэп )
=Андрей=
Познакомите с этой статистикой?\
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Hardware.html#ecc-memory
Не статистика, обсуждение
https://www.truenas.com/community/threads/ecc-vs-non-ecc-ram-and-zfs.15449/page-15
Ivan
GRUB does not support all of the zpool features. See spa_feature_names in grub-core/fs/zfs/zfs.c. This step creates a separate boot pool for /boot with the features limited to only those that GRUB supports, allowing the root pool to use any/all features. Note that GRUB opens the pool read-only, so all read-only compatible features are “supported” by GRUB.
Владимир
GRUB does not support all of the zpool features. See spa_feature_names in grub-core/fs/zfs/zfs.c. This step creates a separate boot pool for /boot with the features limited to only those that GRUB supports, allowing the root pool to use any/all features. Note that GRUB opens the pool read-only, so all read-only compatible features are “supported” by GRUB.
я глянул как это на PVE сделано и там загрузочные данные тянутся с отдельного раздела, не ZFS, у тебя так же?
Ivan
я глянул как это на PVE сделано и там загрузочные данные тянутся с отдельного раздела, не ZFS, у тебя так же?
в pve efi stub вроде юзается. на легаси не знаю как он ставится. а на комп zfs ставилось еще на железо не умеющее в uefi. это позже диски переехали на новое железо. под рукой не было флешки с дебианом, а в имеющуюся livecd убунты я хз как притащить zfs2. так что надеюсь починю загрузку при следующем заезде к компу )
Владимир
в pve efi stub вроде юзается. на легаси не знаю как он ставится. а на комп zfs ставилось еще на железо не умеющее в uefi. это позже диски переехали на новое железо. под рукой не было флешки с дебианом, а в имеющуюся livecd убунты я хз как притащить zfs2. так что надеюсь починю загрузку при следующем заезде к компу )
повторяю что на пве там и легаси и ефи, уже говорил про это, видимо меня не слышно
Владимир
Владимир
первый раздел под легаси второй под ефи
Владимир
когда я ручками разбиваю, под ефи выделяю 37мб, в проксмоксе конечно прям дофига на него выделяют)
Григорий
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Hardware.html#ecc-memory
Не статистика, обсуждение
https://www.truenas.com/community/threads/ecc-vs-non-ecc-ram-and-zfs.15449/page-15
Безумно интересно. Но как это связанно с вашей "статистикой" и утверждение о 16 Гб?
=Андрей=
Безумно интересно. Но как это связанно с вашей "статистикой" и утверждение о 16 Гб?
Я вам лично не обещал никакой статистики и утверждений про 16 гб. Но ине кажутся неправильными заявления, что применение памяти с ECC - деньги на ветер (я утрирую а то и к этим словам привяжетесь, вместоиобсуждения по существу). Выше вам скпзали, что эта проблема с однобитоаыми ошибками в памяти существует, никкда не делась, и обострчется с плотностью чипов. Уж не знаю 16 гиг граница или нет, но ECC, особенно при большой величине памяти в сераере в контексте zfs, совсем вещь нелишняя.
central
насколько вообще вероятно получить не читаемый файл при повреждение одного бита?
Владимир
лучше не проверять наверное))
Григорий
Я вам лично не обещал никакой статистики и утверждений про 16 гб. Но ине кажутся неправильными заявления, что применение памяти с ECC - деньги на ветер (я утрирую а то и к этим словам привяжетесь, вместоиобсуждения по существу). Выше вам скпзали, что эта проблема с однобитоаыми ошибками в памяти существует, никкда не делась, и обострчется с плотностью чипов. Уж не знаю 16 гиг граница или нет, но ECC, особенно при большой величине памяти в сераере в контексте zfs, совсем вещь нелишняя.
Выше участник чата давал конкретное утверждение: "Устройства с объёмом памяти больше 16Гб и без ECC не нужны". Я попросил его предоставить пруфы, на которых зыждится это его утверждения. А зачем вы мне кинули две ссылки на документацию openzfs и старый тред на форуме я пока не понял.
Григорий
насколько вообще вероятно получить не читаемый файл при повреждение одного бита?
На сколько я могу судить по документации zfs и vdo, - системах, в которых в первом случае считаются контролльные суммы данных, а во втором случае происходит сжатие и дедубликация данных, - они очень сильно опираются на целостность и, так сказать, истиность данных в ОЗУ. То есть при ошибке бита могут не столько сами данные побиться сколько метаданые что ли. Что в свою очередь может повлиять на восстановление данных. В остальных же случаях, я считаю, это не настолько сущесственно. Хотя на Хабре видел товарища, который плавает между статьями и рассказывает слезливую историю о том как у него база данных давным-давным билась, потому что память без ECC была. А вот когда он с ECC поставил, всё сразу хорошо стало. Я полагаю что в его истории не одинокие биты были, а частично или полностью неисправная планка ОЗУ.
=Андрей=
Выше участник чата давал конкретное утверждение: "Устройства с объёмом памяти больше 16Гб и без ECC не нужны". Я попросил его предоставить пруфы, на которых зыждится это его утверждения. А зачем вы мне кинули две ссылки на документацию openzfs и старый тред на форуме я пока не понял.
Я вам пруыф предоставить не могу, но скорее всего участник говорил о информации мелькнувшей в интернете о работе исследовательской группы из Женевы (если не ошибаюсь) о проведенных исследованиях, охватывающих большой промежуток времени, на серверах европейских дата-центров. И результаты там совсем не утешительные. И говорилось там про 16GB как о рекомендации, что нужно принимать особые меры, если емкость модуля превышает эту величину. Особенно если нормы плотности превышают некую величину - какую уже не помню... Короче, если интересно можно погуглить, думаю найдется. Группу возглавляла женщина.
Я набрел на это исследование, когда просто изучал вопрос - с ECC или без, строить домашний NAS, так как из этого много чего растет - и проц, и мама, и конечно память. Если с ECC, то серверная мамка, а в мини- ITХ формате мало портов SATA и прочее, прочее....
=Андрей=
Интересно. Благодарю. Ознакомлюсь, если смогу найти.
Однобитовые ошибки на рабочих станциях без ECC (десктопные комплектующие) как правило незаметны и неопасны, так как не приводят к заметным последствиям. А вот на нагруженной хранилке в продакшене - это может быть чревато, согласны?
=Андрей=
насколько вообще вероятно получить не читаемый файл при повреждение одного бита?
Я выше дал ссылку на форум, там участники общения рассказывают о реальных случаях применительно к FreeNAS/TrueNAS.
Данные могут побиться в памяти до попадания на ZFS, не так ли?
Я читал, мнение одного из разработчиков, что совсем не на 100% однобитовые ошибки приведут к появлению ошибок на zfs, даже на scrub/resilver операциях. Зафиксированы случаи, даже когда сбойная планка НЕ приводила к появлению сбоя zfs. Но при этом он сделал ремарку, что полностью здоровая ZFS не означает, что битые данные не попали на хранение до действия всех механизмов целостности данных zfs.
Григорий
Однобитовые ошибки на рабочих станциях без ECC (десктопные комплектующие) как правило незаметны и неопасны, так как не приводят к заметным последствиям. А вот на нагруженной хранилке в продакшене - это может быть чревато, согласны?
И да, и нет. Считаю что это зависит от программно-аппаратных реализаций конретного решения.
Григорий
А выражение "нагруженая хранилка в продакшене" - это Оооочень расплывчатое выражение. В него вполне попадает как станции по отдаче медиа-контента или сервер 1С:Предприятия крупной компании, так и кластер Ceph с S3 для хранения бэкапов.
=Андрей=
А какая разница. Продакшен есть продакшен... Это недома фотачки имузычку хранить. Эти данные каких-то денег стоят.
=Андрей=
И да, и нет. Считаю что это зависит от программно-аппаратных реализаций конретного решения.
Тут - да, что-то возразить трудно. Вот и ладушки ) Но ECC - это уже просто стандарт.
Григорий
Тут - да, что-то возразить трудно. Вот и ладушки ) Но ECC - это уже просто стандарт.
Вот что подумалось: а какая ОЗУ используется в аппратных raid-контроллерах или кэшах в накопителях?
=Андрей=
Вот что подумалось: а какая ОЗУ используется в аппратных raid-контроллерах или кэшах в накопителях?
Я читал описание SSD и там упоминалось о ECC. Достал LSI SAS 9271-8i на нем 5 чипов RAM Hynix. Полагаю, тоже с ECC
Алексей
Я выше дал ссылку на форум, там участники общения рассказывают о реальных случаях применительно к FreeNAS/TrueNAS.
Данные могут побиться в памяти до попадания на ZFS, не так ли?
Я читал, мнение одного из разработчиков, что совсем не на 100% однобитовые ошибки приведут к появлению ошибок на zfs, даже на scrub/resilver операциях. Зафиксированы случаи, даже когда сбойная планка НЕ приводила к появлению сбоя zfs. Но при этом он сделал ремарку, что полностью здоровая ZFS не означает, что битые данные не попали на хранение до действия всех механизмов целостности данных zfs.
достаточно просто накатить снапшот неверно и у вас всё протухнет.
=Андрей=
достаточно просто накатить снапшот неверно и у вас всё протухнет.
Типун вам... ))) у меня ничего не протухнет. ))
Алексей
типун мне, у меня протухло
Алексей
и всё. Перемелет всё, и то что в первом снапшоте в том числе
=Андрей=
Ничего не понятно. То что перемелет, это ясно, но протухло то почему? И какое это имеет отношение к обсуждению ECC?
Алексей
данные будут повреждены, и с ECC и без ECC
=Андрей=
Ну а разобрались почему это произошло?
Алексей
просто разработчики так усиленно выделяют что "если данные не были повреждены до записи"
=Андрей=
просто разработчики так усиленно выделяют что "если данные не были повреждены до записи"
А что у вас за ось? Я на соляре с таким поведением не встречался, а фрееnas пока тестирую.
Алексей
прокс
Алексей
говорят это пофиксили недавно)
Алексей
но я уже не копал
=Андрей=
антиресно.... ((
George
просто разработчики так усиленно выделяют что "если данные не были повреждены до записи"
ну вы всё же баги в коде выделяйте отдельно, их никто исключить не может. Вот контекст баги, про которую Алексей говорит https://github.com/openzfs/zfs/issues/6224
Алексей
ну я без претензий
Алексей
сам ССЗБ
Алексей
надо было проверять а не доверять
=Андрей=
Ну тем не менее к ECC, как я понял, это отношения не имеет.
Алексей
да, просто данные могут быть повреждены и с ECC)
Алексей
да просит меня аллах, просто я всё еще под впечатлением последствий)
=Андрей=
Все не проверишь, приходится доверять.
=Андрей=
да, просто данные могут быть повреждены и с ECC)
Конечно могут, тем более если баг. Но с ECC вероятность меньше, если сбой в самой подсистеме памяти возник....
=Андрей=
ну вы всё же баги в коде выделяйте отдельно, их никто исключить не может. Вот контекст баги, про которую Алексей говорит https://github.com/openzfs/zfs/issues/6224
Спасибо за ссылку. Почитал. Но не понял баг пофиксили или нет? что в сухом остатке?
George
Спасибо за ссылку. Почитал. Но не понял баг пофиксили или нет? что в сухом остатке?
по ссылке была информация о PR, емнип в 2.0 фикс приехал
central
Raid 0 из одного диска?
edo1
ИМХО никак. зато можно добавить небольшой ssd под special, ext4 так не умеет (вернее умеет со всякими bcache, но это немного другое)
edo1
я же ответил, что никак )
zpool iostat -vl 10 покажите что выводит под нагрузкой
edo1
edo1
большой recordsize, похоже, оправдывает себя: обмен с hdd идёт крупными блоками
edo1
но разделы пока не заполнены, потом ситуация может ухудшиться из-за фрагментации
edo1
@ivan0biwan 2 мегабайта — не так уж мало, попробуйте так же увеличить recordsize
edo1
но zfs пишет много метаданных (мелких по определению), без ssd будет грустно
edo1
redundant_metadata=most
но принципиально ничего не изменит
edo1
а что вы понимаете под удвоенной производительностью?
edo1
на однопоточном чтении мелкими блоками никакого улучшения производительности быть не может
edo1
при последовательных операциях и многопоточной нагрузке несколько дисков могут быть быстрее, конечно
edo1
на однопоточном чтении мелкими блоками никакого улучшения производительности быть не может
старое «9 женщин не могут родить ребёнка за месяц»
edo1
давайте лучше с чтением )
вот смотрите, нам нужно прочитать файл размером в 32 килобайта, считаем, что метаданные в кэше.
что нужно сделать: определить диск на котором лежат данные, определить место, где они лежат, дать команду диску.
диск начинает подводить головку к нужной дорожке, потом ожидает когда нужный блок окажется под головкой и читает его
edo1
по сути вся задержка определяется диском
edo1
и добавление 100500 дисков никак ситуацию не изменит, задействован будет только один
edo1
и даже если мы задействуем два диска, мы просто заставим оба диска дёргать головками, быстрее не получится
edo1
среднее время поиска условно 10мс, скорость линейных операций опять уже условно 100 мегабайт в секунду
edo1
считаем, чтение одного мегабайта с диска 20мс, чтение двух мегабайт — 30мс
edo1
выигрыш есть, но не такой большой
central
LRU LFU
central
Уже в ОЗУ