The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз GhostBSD 18.10, opennews (??), 01-Ноя-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


17. "Релиз GhostBSD 18.10"  –3 +/
Сообщение от Иронимemail (?), 01-Ноя-18, 23:57 
Для ZFS нужна регистровая озу, или не стоит ей доверять данные представляющие существенную важность.
Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз GhostBSD 18.10"  +2 +/
Сообщение от Аноним (-), 02-Ноя-18, 00:10 
> Для ZFS нужна регистровая озу, или не стоит ей доверять данные представляющие
> существенную важность.

А может, все-таки, ECC? Регистры - немного про другое ;)

Ответить | Правка | Наверх | Cообщить модератору

33. "Релиз GhostBSD 18.10"  +/
Сообщение от Аноним (33), 02-Ноя-18, 00:53 
Я ловил битую память два раза в жизни, лет 10 назад под UFS и пару лет назад под ZFS. UFS после перезагрузки слетела целиком и полностью. А ZFS после замены памяти и скраба даже показала мне какие конкретно файлы побились, при этом снапшоты остались целёхоньки. Scrub of death я, конечно, не отрицаю, но пока его не сделать ZFS намного надёжнее любой другой ФС, даже при битой памяти.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

34. "Релиз GhostBSD 18.10"  –1 +/
Сообщение от Аноним (28), 02-Ноя-18, 00:59 
Что на счёт хамера?Вторую ветку уже рекомендуют как основную.
Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз GhostBSD 18.10"  +1 +/
Сообщение от Аноним (-), 02-Ноя-18, 02:01 
> целиком и полностью. А ZFS после замены памяти и скраба даже
> показала мне какие конкретно файлы побились,

Проблема в том что если память без ECC, данные могли побиться например ДО того как их чексум при записи будет посчитан. И в этом случае уверенность ФС в исправности файла - вовсе не означает что этот файл и правда ОК. Оно означает только то что ФС не испортила по своему мнению данные пока они лежали на блинах. Но если данные портятся в RAM - радости то с того?

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

60. "Релиз GhostBSD 18.10"  +1 +/
Сообщение от Аноним (60), 02-Ноя-18, 10:25 
Ну так фс об этом и не узнает, к ней тут уже вопросов нет.
Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз GhostBSD 18.10"  +/
Сообщение от Аноним (123), 04-Ноя-18, 01:48 
> Ну так фс об этом и не узнает, к ней тут уже вопросов нет.

Но данные то в конечном итоге пролюблены, а формальные отмазки - ну мы ж не в военкомате...

Ответить | Правка | Наверх | Cообщить модератору

61. "Релиз GhostBSD 18.10"  +/
Сообщение от danonimous (?), 02-Ноя-18, 13:11 
http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo.../

Тут объясняют, что scrub of death - это миф.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

84. "Релиз GhostBSD 18.10"  –1 +/
Сообщение от пох (?), 02-Ноя-18, 23:16 
к сожалению, "объясняют" - теоретики.
А вот фринасеры - практики, причем, в отличие от теоретиков, даже работающих в дельфиксе, у них реально громадное количество разных систем в поле зрения.

Результаты практики - печальные, увы:
https://forums.freenas.org/index.php?threads/zfs-import-cras.../
https://forums.freenas.org/index.php?threads/freenas-crash-s.../

и нет, никакая другая из популярных fs не умеет вставать в позу рака "пул не импортится" - даже сильно разрушенную ext4 можно смонтировать в r/o и добывать оттуда данные без мистических инструментов (которых, на самом деле, не существует)

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

Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз GhostBSD 18.10"  –1 +/
Сообщение от пох (?), 02-Ноя-18, 23:34 
и до кучи, передайте этому "знатоку", что sha256 в стандартных zfs не используется, в виду дикой тормознутости. Если он даже этого не знает - грош цена и остальным его пальцевысосанным идеям.

freebsd использует по умолчанию fletcher4 (он не криптостоек, но для этих целей и не требуется)
иллюмосовцы рекомендуют к использованию edonr (и [вроде бы]криптостоек, и в десятки раз быстрее sha256) но, кажется, загружаться с такого пула по сей день не научились (и не спрашивайте меня, нахрена их загрузчику ненужный "ум" и зачем он вообще эти суммы лезет проверять, и тем более- почему не может просто загрузить что прочиталось, если проверить не вышло, а загружаться больше не с чего. Это типикал zfs story, ага, у них все так.)

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

39. "Релиз GhostBSD 18.10"  +3 +/
Сообщение от xm (ok), 02-Ноя-18, 01:35 
ECC. На самом деле для любой (!) FS нужна память с проверкой на ошибки просто ZFS первая стала об этом говорить.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

54. "Релиз GhostBSD 18.10"  –1 +/
Сообщение от пох (?), 02-Ноя-18, 09:50 
просто фифекты разные - "любая fs" просто тихо что-то у себя портит, записывая битые битики, а потом, лет может и через пять, когда ты запустишь fsck, получишь пачку непонятного в lost+found и решишь... а хрен его знает, что ты решишь - "пять лет эти файлы не трогал, чего это оно, глюкало это ваша ext4".

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

А вот zfs имеет противную привычку постоянно перепроверять контрольные суммы метаданных, и если внезапно что-то не сошлось - при хорошем раскладе автоматически восстановится. При вполне возможном - пул ВНЕЗАПНО превращается в тык...оффлайн, и хорошо если после scrub импортится и монтируется обратно. И при этом еще и ее заботит целостность и непротиворечивость метаданных,а не твоих данных - считается, что все порно с крокодилами должно быть либо гарантированно целым, либо скачай заново.

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

с raidz все становится еще интереснее, но, учитывая кто, как и когда его взялся переписать с нуля, сейчас все равно только упopотые могут рисковать им пользоваться вне oracle solaris.

Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз GhostBSD 18.10"  +/
Сообщение от iZENemail (ok), 04-Ноя-18, 01:09 
> с raidz все становится еще интереснее, но, учитывая кто, как и когда его взялся переписать с нуля, сейчас все равно только упopотые могут рисковать им пользоваться вне oracle solaris.

Ох, зелен виноград...

Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз GhostBSD 18.10"  +/
Сообщение от Аноним (-), 04-Ноя-18, 01:55 
> Ох, зелен виноград...

А ты попользовался? И питание сдернуть внезапно - пробовал? А глюкавые диски использовать?

Пох то видимо стреляный воробей и догадыается почему в btrfs какой-нибудь raid56 стабильным громко и во всеуслышание называть не хотят, хоть он как бы есть и как бы работает. Там получается довольно сложное взаимодейтсвие уровней stripe/блочных устройств и всего что касается ФС (включая всякие cache и проч). И там довольно много мест где может выйти лажа, возможно даже в виде когда это ЗА пределами того что логика ФС и уровня RAID может сжевать.

...а вот далее логика ФС не очень ожидает западло когда RAID вдруг не удастся прочитать вообще ни из одной копии/восстановить по избыточности например. Что после такого может случиться с ZFS'ом ты можешь ту историю с закатом солнца вручную на лисяре почитать. И хотя вот конкретно тот вариант проблемы закостылили, сколько еще таких приколов есть - да кто ж его знает при кодет то такого размера? :)

В btrfs'е то я в таком раскладе чертыхнусь и солью данные usermode читалкой, недеструктивно читающей данные из ФС без монтирования, возможно потыкавшись в разные generation структур в надежде найти относительно неубитую версию деревьев, которые эта штука сносно распарсит, достав мне все нужные файлы. А что делают в таком случае ZFSники я не знаю. На лисяре хардкорили с HEX-редактором, но сколько из опеннетчиков так сможет, даже если захочет? Человек 5 из всех посетителей вообще?

Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз GhostBSD 18.10"  +/
Сообщение от iZENemail (ok), 04-Ноя-18, 14:05 
>> Ох, зелен виноград...
> А ты попользовался? И питание сдернуть внезапно - пробовал? А глюкавые диски
> использовать?

С FreeBSD 9 использую RAIDZ. Успел заменить в нём два диска.

% zpool status store
  pool: store
state: ONLINE
status: One or more devices are configured to use a non-native block size.
    Expect reduced performance.
action: Replace affected devices with devices that support the
    configured block size, or migrate data to a properly configured
    pool.
  scan: resilvered 560G in 0 days 03:50:20 with 0 errors on Mon Oct 29 15:56:39 2018
config:

    NAME        STATE     READ WRITE CKSUM
    store       ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        ada3    ONLINE       0     0     0
        ada1    ONLINE       0     0     0  block size: 512B configured, 4096B native
        ada2    ONLINE       0     0     0  block size: 512B configured, 4096B native

errors: No known data errors

(На момент создания массива диски были с 512 байтовым сектором. Сейчас выпускают диски с сектором 4k байт - поэтому предупреждения о несоответствии. Привести к общему "знаменателю" с помощью GEOM NOP не удалась - нужно перестраивать массив с нуля.)

Ответить | Правка | Наверх | Cообщить модератору

142. "Релиз GhostBSD 18.10"  +/
Сообщение от Аноним (142), 05-Ноя-18, 02:28 
> С FreeBSD 9 использую RAIDZ. Успел заменить в нём два диска.

И ты думаешь что на этом наборе ты узрел все глюки на которые оно способно? Оптимизм это хорошо, конечно. Но когда фэйсбук например на хомяках потестил, оказалось много очень странных багов, когда на 35-м терабайте, в полнолуние високосного года случается какая-то фигня. Если терабайтов менее 35 или год не високосный - все работает!

> errors: No known data errors

А он у тебя хоть 1 ошибку то исправлял? Или ты хотел сказать что ты погонял в тепличных условиях и сделал вывод что все зашибись? %)

> (На момент создания массива диски были с 512 байтовым сектором. Сейчас выпускают
> диски с сектором 4k байт - поэтому предупреждения о несоответствии.

А оно что, прямо 512-байтными блоками орудовало? И это, у тебя и правда там всего 560 гиг данных?

> Привести к общему "знаменателю" с помощью GEOM NOP не удалась - нужно
> перестраивать массив с нуля.)

Ну нифига себе.

Ответить | Правка | Наверх | Cообщить модератору

147. "Релиз GhostBSD 18.10"  +/
Сообщение от iZENemail (ok), 05-Ноя-18, 14:09 
> А он у тебя хоть 1 ошибку то исправлял? Или ты хотел
> сказать что ты погонял в тепличных условиях и сделал вывод что
> все зашибись? %)

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

Ответить | Правка | Наверх | Cообщить модератору

133. "Релиз GhostBSD 18.10"  +/
Сообщение от iZENemail (ok), 04-Ноя-18, 14:09 
> ...а вот далее логика ФС не очень ожидает западло когда RAID вдруг
> не удастся прочитать вообще ни из одной копии/восстановить по избыточности например.
> Что после такого может случиться с ZFS'ом ты можешь ту историю
> с закатом солнца вручную на лисяре почитать. И хотя вот конкретно
> тот вариант проблемы закостылили, сколько еще таких приколов есть - да
> кто ж его знает при кодет то такого размера? :)

У меня RAIDZ ни разу не оставался в offline из-за отказавшего диска. Даже во время перестройки массива он остаётся доступным на запись-чтение.


Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

144. "Релиз GhostBSD 18.10"  +/
Сообщение от Аноним (142), 05-Ноя-18, 02:34 
> У меня RAIDZ ни разу не оставался в offline из-за отказавшего диска.

Напоминает анекдот про войну чукч и китайцев :)

> Даже во время перестройки массива он остаётся доступным на запись-чтение.

И это хорошо. Но вопрос был не про это. Диски могут дохнуть очень по разному. И не всегда допущения RAID оправдываются. Более того - если во время активной записи питание слетит или ресет нажать или что еще не так - насколько механика ФС правильно взаимодействует с механикой RAID и это правильно в блочный уровень отправляется, и там не поднасрут всякие кэши и проч - целый очень отдельный вопрос, здорово зависящий от конкретики конфигурации. Можешь на свой страх и риск понажимать ресет при активной записи, но если что пойдет не так - я не виноват.

Ответить | Правка | Наверх | Cообщить модератору

146. "Релиз GhostBSD 18.10"  +/
Сообщение от iZENemail (ok), 05-Ноя-18, 14:05 
Что такое RAID-Z? https://www.stableit.ru/2010/08/raid-z.html
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру