forum.opennet.ru

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

Оглавление

В OpenZFS выявлена ошибка, которая может привести к повреждению файлов, opennews (??), 23-Ноя-23, (0) [смотреть все]

Надежная ФС Прям как оригинальная ZFS, только пишется не всякими мутными оракла, Аноним (1), 11:30 , 23-Ноя-23, (1) +20 //

А вы чего хотели Всё, что человечество изобретало последние 50 лет, впихнули в , Аноним (7), 11:42 , 23-Ноя-23, (7) +2 //

В энергосистему из которой вы электричество качаете - впихнули все что человеч, Аноним (-), 18:11 , 23-Ноя-23, (149) –1 //

в энергетике хорошо работает естественный отбор если делать плохо, то кого-то л, Аноним (313), 14:19 , 25-Ноя-23, (313)

Припоминая как дефолтсити вырубился в 2005 - иногда, таки, естественный отбор вы, Аноним (319), 23:29 , 25-Ноя-23, (319)

Гм Да Записываем - про энергосистемы вы знаете примерно ничего - но аналогия, User (??), 10:00 , 27-Ноя-23, (364)

Как всегда больше всех ноют те, у кого ZFS вообще нет , Аноним (9), 11:46 , 23-Ноя-23, (9) +19 //

Точно, надо попользоваться, похерить файлы, а уж потом ныть , Аноним (21), 12:06 , 23-Ноя-23, (21) +1 //

О чем как раз и сообщение, на которое вы ответили Пишут только те, у кого её ни, Всем Анонимам Аноним (?), 13:53 , 23-Ноя-23, (58) +3

У меня был опыт использования ZFS для файлов и баз данных Раз в несколько дней , None (??), 15:23 , 23-Ноя-23, (102)

Настоящее инженерное решение А что ж тогда оно у других работает и со значи, OpenEcho (?), 15:48 , 23-Ноя-23, (109) +1

ой-ли , pin (??), 18:52 , 23-Ноя-23, (158)

Я боюсь, вы промахнулись кнопкой - ответить , т к я такой херней не страдаю, OpenEcho (?), 01:42 , 24-Ноя-23, (214)

Та же фигня, бро, только с глустером , YetAnotherOnanym (ok), 11:00 , 24-Ноя-23, (244)

не, ну он хотя бы - прикольный , пох. (?), 17:12 , 26-Ноя-23, (347)
Эм Postgres поверх glusterfs Оно и поверх ZFS-то выглядит интересно, но гл, User (??), 10:02 , 27-Ноя-23, (365)

uname -a skipped 9 0-RELEASE FreeBSD 9 0-RELEASE 0 Tue Jan 3 07 46 30 UTC 2, tim2k (ok), 16:07 , 23-Ноя-23, (117) +2

Так оно у тебя в рефлинки и не умело никогда Нет фичи - нет проблем , Аноним (-), 18:12 , 23-Ноя-23, (150)

Так о том и речь Если фича не нужна, не беги обновляться , Аноним (153), 18:32 , 23-Ноя-23, (153)

Правильно, зачем кому-то надо 100 легкий, эффективный моментальный дедуп без , Аноним (-), 18:51 , 23-Ноя-23, (157)

Я так понимаю у тебя проц вчерашнего выпуска, память, материнка навороченная Че, Аноним (174), 21:21 , 23-Ноя-23, (174)

Потом довольно часто почему-то оказывается что такие технологии и сотрудники фир, Аноним (-), 22:00 , 23-Ноя-23, (178) –1

Только вот эта пафосная демагогия никак не влияет на наличиеzfs snapshotzfs clon, Аноним (180), 22:48 , 23-Ноя-23, (180)

Ну то-есть вы хотите сказать, что кодеры делавшие фичу - позеры и страдальцы фиг, Аноним (202), 00:57 , 24-Ноя-23, (202)

Ну то-есть мы опять наблюдаем фирменное 294-ое сруливание с темы , Аноним (180), 01:11 , 24-Ноя-23, (207)

Если хотелось мое мнение по теме, посмотрев на баг трек с какими-то несчастными , Аноним (-), 01:48 , 24-Ноя-23, (215)

вот не надо меня пугать, мне после отвалов btrfs еще на zfs такого не хватало , анон (?), 17:14 , 23-Ноя-23, (135) +1

Просто в BTRFS отвалы тоже из ZFS позаимствованы , EULA (?), 10:57 , 24-Ноя-23, (243) +1

Именно поэтому у меня её нет и никогда не будет , Аноним (32), 12:34 , 23-Ноя-23, (32) +2 //

Да ты и дальше на FAT сиди , BorichL (ok), 14:27 , 23-Ноя-23, (87) +1

Где-то fat норм использовать, только тебе в твоём коворкинге про это не расскажу, Аноним (129), 17:02 , 23-Ноя-23, (129) –1

Учитывая что первый вообще на integrity данных с прибором клал У него чексум не, Аноним (-), 18:38 , 23-Ноя-23, (155) –1

Ну, если у тебя data integrity парой уровней выше или наоборот, ниже - то почему, User (??), 11:22 , 28-Ноя-23, (385)

1 Это такое довольно большое если 2 Которое к тому же имеет свойство стоить, Аноним (-), 21:37 , 28-Ноя-23, (394)

Сюрприииз Как-то так оно в реальном мире и работает Enterprise у дешевле запла, User (??), 21:49 , 28-Ноя-23, (395)

А чего ты HPFS386 и JFS забыл, или тогда ещё под стол пешком ходил , BorichL (ok), 19:50 , 23-Ноя-23, (170)

Это не нытьё, а злорадство как хорошо, что на моей любимой ext4 ничего подобног, ИмяХ (ok), 13:54 , 23-Ноя-23, (59) +1 //

Больше выглядит как я не разобрался, поэтому у меня ничего нету Половина винд, Аноним (9), 14:15 , 23-Ноя-23, (71) +7

Сам-то понял, каким дном свою ZFS выставил, защитничек , Аноним (136), 17:14 , 23-Ноя-23, (136)

Ну да, как же они на ехт4 то без чексумм узнают что у них там что-то повредилось, Аноним (125), 16:42 , 23-Ноя-23, (125) –1
На твоей любимой EXT4 ты узнаешь что данные в труху исключительно по факту , Аноним (-), 18:40 , 23-Ноя-23, (156)

git blame , Пряник (?), 11:47 , 23-Ноя-23, (11) –1
факела бсдлюбов особенно хороши ext4 используй, Аноним (16), 11:54 , 23-Ноя-23, (16) +2 //

Но вы же оба виндузятники, там нет ext4, Аноним (9), 11:57 , 23-Ноя-23, (18) +4 //

там зато есть единственная существующая утилита для восстановления файлов рухнув, пох. (?), 12:35 , 23-Ноя-23, (34) –2

Нужны грязные подробности, если это не про поддержку атрибутов в разных версиях , Аноним (153), 13:52 , 23-Ноя-23, (57) +1

если не умеешь в гугль - воспользуйся хотя бы поиском по сайту , пох. (?), 14:11 , 23-Ноя-23, (66)

Это оно https lkml org lkml 2018 12 27 155 d_off field in struct dirent and 3, Аноним (262), 13:14 , 24-Ноя-23, (262)

не оно, но я не удивлюсь если тут и виндовый драйвер не поможет Спасибо, в копи, пох. (?), 16:49 , 26-Ноя-23, (337) +1

это какая Там - это где , Аноним (-), 14:02 , 23-Ноя-23, (61)

где-где - ввенде гуглем пользоваться уж как-нибудь сам учись , пох. (?), 14:10 , 23-Ноя-23, (65) –3

Да ващет в этом нашем btrfs - такая штука встроена прям в штатный тулкит ФС И р, Аноним (-), 18:54 , 23-Ноя-23, (159)

И об этом ты ещё до войны разговаривал с господином окружным начальником , Аноним (179), 22:07 , 23-Ноя-23, (179)
Это какие Которые ZFS сначала закрыли, чтобы барыжить, а потом поняли, что позд, Аноним (262), 13:10 , 24-Ноя-23, (261) +1

Чего кого В btrfs офлайн парсер, позволяющий к тому же потыкаться в разные точк, Аноним (-), 18:30 , 24-Ноя-23, (283)

zfs была открыта задолго до того как оракле понял, что она крута Так что Крис, Аноним (368), 10:36 , 27-Ноя-23, (368)

Оракл вообще купил в основном из-за соляры и явы как я понимаю, ну и чтобы энтер, Аноним (319), 20:25 , 27-Ноя-23, (372)

Ну кагбыда, но в реальной жизни почему-то нагруженный MsSQL под NTFS запустить м, User (??), 11:50 , 28-Ноя-23, (386)

Мне вот интересно - чего такого нагруженного на вот именно MS SQL вообше запус, Аноним (390), 19:26 , 28-Ноя-23, (390)

И вот эти вот конпелятели ядра и заменятели катриджей что-то там про enterprise , User (??), 21:01 , 28-Ноя-23, (392)
Скрыто модератором, Аноним (-), 22:00 , 28-Ноя-23, (396)
Я готов поспорить что корпы где я это все щупал были в фортуне-500 сильно выше в, Аноним (390), 22:06 , 28-Ноя-23, (397)
Опыт замены катриджей офигенно релевантен вопросу, да Уровень своих не знаний , User (??), 07:51 , 29-Ноя-23, (402)

Скрыто модератором, Аноним (-), 02:41 , 29-Ноя-23, (400)

Работает на серверах уже кучу лет, так что в надёжности можно не сомневаться А н, Аноним (30), 12:31 , 23-Ноя-23, (30) +2 //

Просвяти на каких именно серверах и чем обусловлен выбор , Аноним (32), 12:35 , 23-Ноя-23, (33) //

Спроси у операторов большой тройки, что они сейчас используют- , BeLord (ok), 13:38 , 23-Ноя-23, (50)

Венду, венду и а, вот - венду , пох. (?), 14:12 , 23-Ноя-23, (67)

хоть новость бы дочитал Повреждение файлов проявляется при достаточно редком сте, Аноним (90), 14:29 , 23-Ноя-23, (90) //

Угу Проблема в том, что узнать, стекло или не стекло - невозможно Пока не пойм, Tron is Whistling (?), 14:38 , 23-Ноя-23, (94)
Вспомните про закон больших чисел Есть ZFS будет на каждом ПК, то внезапно редк, Kuromi (ok), 15:47 , 23-Ноя-23, (108) +1 //

Так наличие ZFS на компьютере - и есть то редкое обстоятельство , Аноним (7), 17:48 , 23-Ноя-23, (145)

Я понимаю, что по утру бзднуть хочется, но оглядываться все же не мешаетhttps , OpenEcho (?), 15:44 , 23-Ноя-23, (107)

Ни на что не намекаю, но в Btrfs такой проблемы нет , Аноним (3), 11:35 , 23-Ноя-23, (3) –4 //

А какая есть , Аноним (7), 11:40 , 23-Ноя-23, (6) +7 //

Ну например слишком стабильно работает, даже как-то скучно становится Приходитс, Аноним (3), 11:42 , 23-Ноя-23, (8) –5 //

Пишешь из будущего , Аноним (9), 11:47 , 23-Ноя-23, (10) +6

Из будущего альтернативной реальности - форкнулась где-то в 2010м Там у них btr, пох. (?), 12:31 , 23-Ноя-23, (28)

А зачем выкидывать то Btrfs как раз до ума более-менее довели А это только нач, Аноним (-), 00:41 , 24-Ноя-23, (195)

а если нагрузить по методике Шишкина - что будет или от чего там ntfs умирала , glad_valakas (?), 12:36 , 23-Ноя-23, (35)

по той самой методике, которую он никому не раскрыл , Аноним (3), 13:05 , 23-Ноя-23, (42) +1

если подумать и поработать руками, то можно воспроизвести задавшись вопросом ка, glad_valakas (?), 17:07 , 23-Ноя-23, (131)

ну подеградируй, подеградируй мое дерево Деградируй мое дерево полностью Ты см, Аноним (3), 17:19 , 23-Ноя-23, (137) +1
Меньше слушайте всяких экспертовDate Fri, 18 Jun 2010 15 32 16 0200From Edward , Аноним (269), 13:58 , 24-Ноя-23, (269)

нашел время прочитать наконец-то ахренеть, они несходящийся алгоритм ухитрили, нах. (?), 23:53 , 27-Ноя-23, (376)

Как Васян, наслышавшийся анекдотов про у меня на виртуалке всё работает , я не, Аноним (269), 06:36 , 28-Ноя-23, (381)

Ну вы то с похом офигенные эксперты Толи на ZFS осыпающемся, толи вообще на NTF, Аноним (-), 08:23 , 28-Ноя-23, (382)

Ну ты то знаешь, зачем в ядре нужен префикс lock , Аноним (269), 05:24 , 29-Ноя-23, (401) +1

Создать файлуху на 600 мегов и забить ее мелкотой Можно, но вот что доказывает , Аноним (202), 00:56 , 24-Ноя-23, (201) –2

Уже много лет на btrfs, тьфу-тьфу, ни разу пока проблем не вылезло Но, это не з, lucentcode (ok), 21:59 , 23-Ноя-23, (177) +1

Ну так 1 btrfs интегрирован с майнлайном на тему разработки 2 авторы оного е, Аноним (216), 02:08 , 24-Ноя-23, (216)

Недообследованная , iZEN (ok), 12:16 , 26-Ноя-23, (334)

Текст в интернете всегда прав , Пряник (?), 11:49 , 23-Ноя-23, (14) +3
Да ну А что ж тогда на редите приколоченные гвоздями проблемы весят, OpenEcho (?), 15:58 , 23-Ноя-23, (113) //

это ошибка выжившего Когда бтрфс работает, никто не приколачивает гвоздями пост, Аноним (3), 16:23 , 23-Ноя-23, (122) –1 //

Так, я не про них, я про те что уже ОЧЕНЬ долго гвоздями прибиты, OpenEcho (?), 01:35 , 24-Ноя-23, (211)
Гораздо чаще встречается ошибка вдовы - у меня сдохло, значит, у всех сдохнет , YetAnotherOnanym (ok), 11:07 , 24-Ноя-23, (245)

товарищмайор, тут вдовроссии дискредитируют , пох. (?), 17:14 , 26-Ноя-23, (348)

Продолжаем использовать ext4 Держите в курсе , beck (??), 11:37 , 23-Ноя-23, (4) +4 //

ntfs , Аноним (22), 12:10 , 23-Ноя-23, (22) +1 //

fat16 , Аноним (307), 10:33 , 25-Ноя-23, (307)

Шишкин прав был Дерм ще все эти ваши zfs, btrfs и т п , Аноним (13), 11:49 , 23-Ноя-23, (13) +2 //

FAT16 сила , Ахмат (?), 12:19 , 23-Ноя-23, (24) +4 //

Шишкин сила Рейзер5 придет - порядок наведет , Аноним (26), 12:23 , 23-Ноя-23, (26) +1 //

Ему же пожизненное дали , tim2k (ok), 16:12 , 23-Ноя-23, (120)

Файловой системе , Анонис (?), 21:40 , 23-Ноя-23, (175) +3
Шишкину то Он конечно мерзкий зануда, но не настолько же , Аноним (216), 02:09 , 24-Ноя-23, (217) +4

win95 cih с тобой не согласен , Аноним (29), 12:31 , 23-Ноя-23, (29) +2
Единственная файловая система которую Я осилил сам запрограммировать за свою жиз, Анонимпс (?), 18:38 , 23-Ноя-23, (154) +1

btrfs - лучшая фс, penetrator (?), 14:12 , 23-Ноя-23, (68) –3 //

Худшая из всех что тестировал , Аноним (96), 14:49 , 23-Ноя-23, (96) +6 //

Скрыто модератором, Аноним (-), 19:13 , 23-Ноя-23, (161) –1
ога, тестировал он, во сне, penetrator (?), 08:06 , 24-Ноя-23, (227) –1

Ну он то как самый умный - не релизнул ФС вообще, reiser3 слил - нет файлух, нет, Аноним (-), 19:12 , 23-Ноя-23, (160)

Ооооо, мне тут недавно один специалист со стажем расхваливал ZFS Говорил, что, еропка (?), 11:58 , 23-Ноя-23, (19) –1 //

OpenZFS был основан и портирован говнокодер сообществом Linux Не путать с Oracl, Аноним (25), 12:21 , 23-Ноя-23, (25) +2 //

Это эти то https openzfs org wiki Companies говнокодеры Даже боюсь спросить, к, OpenEcho (?), 16:02 , 23-Ноя-23, (115) //

Можно подумать там все эти компании что-то программируют Они просто объединилис, Аноним (153), 18:29 , 23-Ноя-23, (152) +2

несколько штук таки есть И да, это говнокодеры и саботажники Начиная с дельфикс, пох. (?), 19:27 , 23-Ноя-23, (164)

Такой прозрачный намек - бабок хочется Создали себе кучу головняка на ровном, Аноним (-), 21:03 , 23-Ноя-23, (173) –1

Это вам баб Маша в подьезде сказала Кто Амазон студентов на аутсорсе Я здесь м, OpenEcho (?), 01:40 , 24-Ноя-23, (213)

А из того списка только амазон пашет Это обычная практика в наше время Опытный , Аноним (262), 09:57 , 24-Ноя-23, (240)

Т е для тебя без 5-ти минут инженер и фрилэнцер - одно и тоже И на то, что рабо, OpenEcho (?), 12:30 , 24-Ноя-23, (255) –1

конечно нет - первый вообще ничего не умеет, а второй - ну хз, кто это просто ин, нах. (?), 13:30 , 24-Ноя-23, (263)
Я и сам таким был когда-то А в амазоне работают такие же люди, которых сейчас в , Аноним (262), 13:35 , 24-Ноя-23, (264)

Ну, теперь понятен уровень осведомленности о устройстве амазона Читайте дальше, OpenEcho (?), 07:29 , 25-Ноя-23, (304)

Твой источник новостей про самоотверженное кодирование zfs тыжбез5минутинженер-, Аноним (262), 09:49 , 25-Ноя-23, (305)

Видел, потому и говорюЛегче стало Хороших выходных , OpenEcho (?), 18:28 , 25-Ноя-23, (315)

А у амазона нет своей корпоративной почты Что-то в этом списке их нет https gi, Аноним (262), 10:01 , 24-Ноя-23, (241)

Там где идет речь о FSx, то изпользуется корпоративная почта, иначе слишком мног, OpenEcho (?), 12:44 , 24-Ноя-23, (256)

FSx - это амазоновское корпоративное решение поверх openzfs То есть для общей р, Аноним (262), 13:40 , 24-Ноя-23, (266)

Ох уж эти телепаты Для того, чтобы мыши прибегали на сыр, - он должен быть сье, OpenEcho (?), 14:46 , 24-Ноя-23, (274)

Ух ты Так сыр, оказывается, несъедобный И поэтому они на его базе своё решение, Аноним (262), 16:53 , 24-Ноя-23, (278)

Закусывать надо, OpenEcho (?), 07:24 , 25-Ноя-23, (303)

Так он и закусил, видимо, живу плохо вино кислое, сыр плесневелый, машина без , Аноним (319), 01:28 , 26-Ноя-23, (325) +1

Не Oracle ZFS а Sun ZFS Оракул того и гляди закопает эту ФС, NetGhost (?), 22:49 , 23-Ноя-23, (181)

я один из таких D очень жду bcachefs но пока где можно всюду zfs Неделю эксплу, rinat85 (ok), 12:30 , 23-Ноя-23, (27) +2 //

О каком серьёзном продакшне речь Как ни спросишь - оказывается либо подкроватны, Аноним (32), 12:37 , 23-Ноя-23, (36) –1 //

Hetzner в своём storage box использует zfs Это достаточно серьёзный продакшн ил, turbo2001 (ok), 12:53 , 23-Ноя-23, (40) +2

Понятия не имею Хочется рабоче-крестьянского чёткого объяснения - мы используем, Аноним (129), 13:14 , 23-Ноя-23, (44)

Рабоче-крестьянский слив защитан, Аноним (9), 14:20 , 23-Ноя-23, (79) +4
Из того, что наружу торчит - используются снапшоты и квоты с учетом снапшотов , turbo2001 (ok), 14:28 , 23-Ноя-23, (89) +1

Да причём тут они Я спрашиваю лично серьёзные-продуктовики в этом треде как и, Аноним (129), 17:07 , 23-Ноя-23, (132)

Господи Что для Вас означает серьёзные-продуктовики Ну вот мы отнюдь не , 1 (??), 17:35 , 23-Ноя-23, (140)

в netapp - по многим источникам таки какой-то свой клон zfs Вплоть до появлявших, нах. (?), 13:07 , 24-Ноя-23, (260)

Да на своём клоне FreeBSD свой клон ZFS , 1 (??), 13:43 , 24-Ноя-23, (267) +1

Проприетарщики они такие А как апстрим в результате сдохнет и придется волочь н, Аноним (319), 00:24 , 26-Ноя-23, (321)

https openzfs org wiki CompaniesДостаточно Или нужно по кестьянски обяснить,, OpenEcho (?), 16:05 , 23-Ноя-23, (116)

Нет Гуглом я умею пользоваться Вопрос в другом Обьясни, пожалуйста Я последн, Аноним (129), 17:09 , 23-Ноя-23, (133)

Бизнес - это про профит Если ты еще этого еще не понял, то я не верю что ты в б, OpenEcho (?), 01:37 , 24-Ноя-23, (212)

Если рассуждать так, то всё равно даже начиная от небольшой организации в 50 сот, rinat85 (ok), 12:58 , 23-Ноя-23, (41) +1

Больше ничего можно было не писать, спасибо Как я и говорил - наш программист , Аноним (129), 13:19 , 23-Ноя-23, (45) –1

О, великий, снизошёл Даже на таком уровне Возможность собрать надежные зерк, rinat85 (ok), 15:23 , 23-Ноя-23, (101) +3

Есть ощущение, что под словом бэкап вы понимаете что-то не то , Аноним (104), 15:33 , 23-Ноя-23, (104) +1

Нет, есть ощущение, что вы думаете, будто я путаю бэкапы со снапшотами Уже отве, rinat85 (ok), 00:46 , 24-Ноя-23, (199)

Да я с тобой не спорю, ты в самом начале своего пути, очень многое узнаешь позже, Аноним (129), 17:24 , 23-Ноя-23, (138)

Простите, сударь, а вы можете внимательно читать Я про снапшоты написал отдельн, rinat85 (ok), 00:41 , 24-Ноя-23, (196)

Всё, что нужно знать о ZFS , Аноним (7), 17:52 , 23-Ноя-23, (146)

Как говорится пользователи делятся на два вида те кто использует zfs и те кто п, Аноним (30), 00:15 , 24-Ноя-23, (193)
Что нужно делать бэкапы Ну да, нужно, а где не нужно ZFS в рамках своего функц, rinat85 (ok), 00:44 , 24-Ноя-23, (198)

Это какой-то новый вид технического постироничного стендапа , all_glory_to_the_hypnotoad (ok), 13:46 , 23-Ноя-23, (54) –1
Оно уже в -rc 6 7, так что самое время потестировать на своих нагрузках И кстат, Аноним (-), 19:15 , 23-Ноя-23, (162)

Да ну, не может быть такого Вон пох или нах я их путаю вчера же разъяснил - в, Аноним (104), 12:05 , 23-Ноя-23, (20) +2 //

вы будете смеяться, но когда я подбирал себе дистрибутив линукса,рекомендации дл, glad_valakas (?), 12:48 , 23-Ноя-23, (39) //

gentoo - как фряха из портовarch - как фряха из пакетовНе самые плохие рекоменда, Аноним (153), 13:40 , 23-Ноя-23, (52) +2
Вот видишь А промолчал бы про бсд - глядишь, посоветовали бы какой-нибудь минт,, Аноним (104), 15:27 , 23-Ноя-23, (103)
Смотр зачем Я п Арч не выбрал Слишком много и часто возиться надо из-за обновл, Аноним (318), 22:54 , 25-Ноя-23, (318)

Если проблему можно воспроизвести, то почему не найдут регресс через git bissect, Аноним (30), 12:34 , 23-Ноя-23, (31) –1 //

потому что ее можно воспроизвести только с определенной долей вероятности И вопр, пох. (?), 12:39 , 23-Ноя-23, (37) //

Не, вот этот вот бисекс приятно работает в их вырожденном случае игр-однодневок , Tron is Whistling (?), 14:35 , 23-Ноя-23, (92) //

Сколько философов то развелось Сами в жизни больших и сложных систем не видели , Аноним (30), 00:48 , 24-Ноя-23, (200) –3

When in doubt, use brute force Кен Томпсон тоже не видел больших систем , Аноним (269), 14:20 , 24-Ноя-23, (270)

Увы Боюсь что только системный есть еще юзерленд код zfs больше чем все то чт, пох. (?), 16:51 , 26-Ноя-23, (338)

Похоже на твои домысли В новости например про это ни слова Так bisect и создан , Аноним (30), 00:30 , 24-Ноя-23, (194)
Скрыто модератором, Аноним (30), 15:48 , 24-Ноя-23, (277) //

Скрыто модератором, пох. (?), 16:56 , 26-Ноя-23, (339)

Ну, узнаете вы что это имплементация рефлинков косячная И Даже если вы зафикс, Аноним (-), 01:05 , 24-Ноя-23, (205) –1 //

и просто отключаешь эту фичу и живешь счастливо восстановив пул из бэкапа, пото, нах. (?), 11:20 , 24-Ноя-23, (246) //

Когда возникают вопросы вида восстановив пул из бэкапа я рад что все это - не , Аноним (-), 18:06 , 24-Ноя-23, (280)
Судя по довеску к новости - это кажется не поможет, а факап возможно был и раньш, Аноним (319), 01:22 , 26-Ноя-23, (324)

Скорее всего узнаю только на каком изменении баг появился Но этого достаточно ч, Аноним (30), 15:47 , 24-Ноя-23, (276) //

Да в принципе вы правы Но судя по тому что я в багтреке увидел, проблема идет н, Аноним (-), 17:47 , 24-Ноя-23, (279)

Мы уже узнали что нет, не она Она помогла наткнуться на баг, который где-то непо, пох. (?), 16:58 , 26-Ноя-23, (340) //

Да вообще, детектив целый получился По своему интересный, но к счастью, не у ме, Аноним (319), 01:00 , 27-Ноя-23, (355)

Скрыто модератором, OpenEcho (?), 14:42 , 24-Ноя-23, (273) –1 //

Скрыто модератором, пох. (?), 16:59 , 26-Ноя-23, (341) //

Скрыто модератором, OpenEcho (?), 17:49 , 26-Ноя-23, (349)

ЫНа гитхабе https github com openzfs zfs pull 15529 два девелопера спорят, отк, Аноним (104), 12:46 , 23-Ноя-23, (38) +8
Какой-то наш мир очень однобокий Когда новость про BTFS с критическими ошибками , wergus (?), 13:13 , 23-Ноя-23, (43) +7 //

Психология Они думали что их любят за пятачок и розовый бочок, а оказалось чт, Аноним (82), 14:22 , 23-Ноя-23, (82)
Деды на FAT16 сидели - и вы ДОЛЖНЫ страдать За родину, за Сталина и вот это вот, Аноним (9), 14:22 , 23-Ноя-23, (83) –1
Ваш - это какой Что btrfs, что zfs, нарушающие идеологию юникс ФС, имеющие масс, Аноним (86), 14:26 , 23-Ноя-23, (86) –4 //

А вы попробуйте реализовать все фичи без нарушения вашей идеологии Как миниму, аНОНИМ (?), 17:45 , 23-Ноя-23, (142) +3
Вам лишь бы какая, но только бы идеология, чтобы самому думать не надо было Пос, Аноним (165), 19:31 , 23-Ноя-23, (165) +2 //

По мне так философию Unix выше практичности обычно ставят люди постарше когда, Аноним (309), 11:29 , 25-Ноя-23, (309)
Последователи любой религии смотрят на Вас осуждающе , Аноним (307), 22:21 , 25-Ноя-23, (316)

Раввин смотрит на вас с недоумением , пох. (?), 23:15 , 26-Ноя-23, (352)

Да вообще охренеть - оказывается, до того как в кресло КВСа плюхнуться и перевез, Аноним (-), 23:22 , 24-Ноя-23, (300)

Proxmox - неплохая штука, но как же иногда приходится изворачиваться, чтобы избе, None (??), 15:42 , 23-Ноя-23, (105) –1
Потому что брбрфс всегда была кривой и багованной, в здравом уме её использовать, Аноньимъ (ok), 15:42 , 23-Ноя-23, (106) +6 //

Никогда не было Софт это вообще не про железобетонность, а именно про возможнос, Аноним (165), 19:37 , 23-Ноя-23, (166) –1 //

Ломать то что работает как надо - не надо Вот конкретно на диване сидеть и не ло, Аноньимъ (ok), 02:25 , 24-Ноя-23, (220)

Вообще-то она уже good enough для монстров размером с FB У тебя есть прод круче, Аноним (208), 01:13 , 24-Ноя-23, (208) –2 //

Так и вижу excited soiboy face Вау конечно, это целых три диска данных В то врем, Аноньимъ (ok), 02:22 , 24-Ноя-23, (219)

Ну говоря за себя - я так то boy весьма условный, дисков у меня и поболее 3 быва, Аноним (-), 03:05 , 24-Ноя-23, (225)

Да ты не бойся, восстановление пула из бэкапа сллжно будет не заметить , Аноним (-), 18:10 , 24-Ноя-23, (281)
Разработчики btrfs в курсе что фичи надо до релиза тестить И тестов у них есть , Аноним (-), 21:38 , 24-Ноя-23, (291)

Да несколько лет назад в течение довольно длительного времени в реализации ext4 , Аноним (46), 13:21 , 23-Ноя-23, (46) –1 //

Похоже, только там были не нули в файле, а сам файл тупо обрезался до нулевой дл, Аноним (153), 13:49 , 23-Ноя-23, (55)
Если не работает write barrier - это и сейчас может происходить , Tron is Whistling (?), 14:08 , 23-Ноя-23, (64) //

write barrier ни от каких повреждений файлов не спасает Он спасает от автооткат, пох. (?), 14:14 , 23-Ноя-23, (70) //

Почитай повыше - о чём речь Речь об обрезке метаданных В основном сие случаетс, Tron is Whistling (?), 14:20 , 23-Ноя-23, (80)

write barrier всего лишь делает этот кусок ограниченным во времени ценой потери, нах. (?), 11:23 , 24-Ноя-23, (247)

Не ограниченная сверху потеря данных - черт, звучит многообещающе Зато какой сл, Аноним (-), 21:52 , 24-Ноя-23, (292)

Немного не так Если у тебя это не работает в железе - откат вообще сработать не, Аноним (-), 01:33 , 24-Ноя-23, (210)

Ну и я о том же Write barrier должен работать от ведра до конечного диска , Tron is Whistling (?), 09:56 , 24-Ноя-23, (239)

Ну как бы это сказать В идеале, фс, особенно с избыточностью, должна бы пережив, Аноним (-), 23:40 , 24-Ноя-23, (301)

Я за 15 лет на всей инфре ни один раз в бэкап не залез по причине повреждения да, Tron is Whistling (?), 10:07 , 25-Ноя-23, (306)

Это может свидетельствовать о самых разных вещах, как минимум 1 Удачливый тип, Аноним (319), 23:53 , 25-Ноя-23, (320)

а чтобы не заниматься всей вот этой НЕВМЕНЯЕМОЙ ХРЕНЬЮ вместо эксплуатации си, Аноним (-), 01:29 , 24-Ноя-23, (209) //

Та же проблема как только у тебя факапнется метадата в силу программной ошибки , Tron is Whistling (?), 09:54 , 24-Ноя-23, (238) //

1 Вообще, сэр, я Data Recovery на полупро уровне с уклоном в линух занимаюсь ма, Аноним (289), 20:09 , 24-Ноя-23, (289)

С перфокарт рекаверишь , Tron is Whistling (?), 21:59 , 24-Ноя-23, (293)

ZFS и без этого бага мусорок Кто её хвалит, снэпшотами то пробовали пользоват, лютый арчешкольник... (?), 13:26 , 23-Ноя-23, (47) //

Ну как бы в CoW размер дельты надо все же контролировать, чудес не бывает Иначе, Аноним (-), 02:14 , 24-Ноя-23, (218) //

ты перепутал со своим любимым lvm У CoW никакой дельты нет Новые записи ВСЕГДА, нах. (?), 11:26 , 24-Ноя-23, (248) –1 //

Я как раз терпеть его не могу, считая отвратительным легаси CoW файлухи это эст, Аноним (-), 22:26 , 24-Ноя-23, (296)

Кто накосячил Опять Клара или чудные линукс-смузихлёбы Пока линуксоиды не начал, Аноним (153), 13:36 , 23-Ноя-23, (48) +2 //

А чё орать-то Сидим на 12-й ветке FreeBSD, в которой православная ZFS, а не САБ, Аноним (-), 14:15 , 23-Ноя-23, (72) +1 //

Так обычно про разработку zfs для freebsd линуксоидами орут сами линуксоиды Они, Аноним (153), 18:02 , 23-Ноя-23, (148)
В 15 вроде тоже норм, жрать не просит, падать не валится, хоть и не труЪ правосл, Лёха (?), 14:47 , 24-Ноя-23, (275)

похоже не клара - клара случайно вляпалась С девушками это бывает Т е вытащили , пох. (?), 14:19 , 23-Ноя-23, (77) //

Ууу, так это санки виноваты, что в линуксе проявилось Ах они, негодники Всё за, Аноним (153), 14:27 , 23-Ноя-23, (88) //

не помню кто там автор - возможно уже наследники из иллюмоса Да, разумеется - эт, пох. (?), 14:56 , 23-Ноя-23, (98)

Всё, доломали легаси , fidoman (ok), 13:37 , 23-Ноя-23, (49) +1 //

в том и дело что понять не могут Если только легаси - выключаешь фичу и спишь с, пох. (?), 15:22 , 23-Ноя-23, (100) //

Судя по https github com openzfs zfs issues 15275 - покой вам только снится Т, Аноним (-), 21:58 , 23-Ноя-23, (176) –1

И что теперь на хайпе, если ZFS стал легаси Файл система БТР , OpenEcho (?), 16:17 , 23-Ноя-23, (121)

Интересно, этим разработчикам не приходила в их светлые головы мысль, что если, fidoman (ok), 13:39 , 23-Ноя-23, (51) //

Ну и чем КОПИЯ авторская раскладка сохранена отличается от копии с автодуплика, 1 (??), 17:12 , 23-Ноя-23, (134) –1 //

Тем, что при повреждении носителя вероятность потерять все копии значительно ниж, Аноним (165), 19:43 , 23-Ноя-23, (167) //

Где Вы берёте таких пользователей На более разумных не хватает ФОТ , Аноним (172), 20:11 , 23-Ноя-23, (172)

У 1 элитарных войнов-линуксойдов денег нет Приходится с быдло99 возиться А ч, Аноним (165), 01:01 , 24-Ноя-23, (203) +1

1 меньше i o, потому что при записи не надо аллочить блоки и обновлять счётчики, fidoman (ok), 20:06 , 23-Ноя-23, (171) //

Т е Вы считаете что при копировании 2Тб файла i o будет меньше чем при clone , 1 (??), 09:47 , 24-Ноя-23, (235)

Не завезли, но есть такая вещь как планирование Копирование запускаем в период , fidoman (ok), 12:50 , 24-Ноя-23, (257)

Ну во первых оно займет место И это стоит денег Во вторых - IO таки грузит И , Аноним (319), 01:35 , 26-Ноя-23, (326)

Тебе в твою светлую голову не приходило что если ты явно запросил сделать тебе р, Аноним (-), 00:42 , 24-Ноя-23, (197) //

Откуда инфа про явно В обсуждении пишут что оно автоматом стало делаться при , fidoman (ok), 09:19 , 24-Ноя-23, (231) –1 //

кому интересны ваши гнупроблемы Предъявляйте претензии авторам корявоутилсов, з, пох. (?), 19:32 , 24-Ноя-23, (286)
С точки зрения файлухи - софт должен явно ioctl вхреначить на это дело, сигняля , Аноним (-), 20:19 , 24-Ноя-23, (290)

Не о сохранности речь, если бы речь была о ней, то, допустим, сделать копию файл, fidoman (ok), 11:19 , 25-Ноя-23, (308)

Если это не интересовало, то идея делать вот именно полную честную копию, когда , Аноним (319), 00:52 , 26-Ноя-23, (322)

Выкинуть бы всё это творчество , но проблема только в том, что другого решения , fidoman (ok), 13:45 , 23-Ноя-23, (53) //

Чего, простите RAID5 6 собственно и позволяет проверить целостность , Tron is Whistling (?), 14:03 , 23-Ноя-23, (62) –1 //

RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстан, fidoman (ok), 15:58 , 23-Ноя-23, (112) //

А вот RAID6 теоретически позволяет если битые данные на одном диске из всех , н, аНОНИМ (?), 17:31 , 23-Ноя-23, (139)

А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает кака, Аноним (-), 03:12 , 24-Ноя-23, (226)

На бтрфс с миррорами -- работает С раид5-6 когда я проверял довольно давно --, аНОНИМ (?), 09:09 , 24-Ноя-23, (228) +1

А я умею читать документацию, и если нечто озвучено как экспериментальная фича -, Аноним (319), 01:16 , 26-Ноя-23, (323)

Я смотрю ты шаришь Не объяснишь по простому, что такое write gap у RAID5 6 , Аноним (165), 19:44 , 23-Ноя-23, (168) //

Не объясню - это ошибочный термин , Tron is Whistling (?), 22:58 , 23-Ноя-23, (182)
И применять его в контексте рейда не следует, термин write gap действительно сущ, Tron is Whistling (?), 23:00 , 23-Ноя-23, (183)

Тогда мне поясни за wright hole , Аноним (204), 01:04 , 24-Ноя-23, (204) +1

Если у вас порча секторов происходит регулярно - есть смысл посмотреть в сторону, Tron is Whistling (?), 14:04 , 23-Ноя-23, (63) //

google bitrot, fidoman (ok), 15:49 , 23-Ноя-23, (110) –3 //

Плджад Там ECC Причём на современных накопителях - не обязательно одноуровневы, Tron is Whistling (?), 23:03 , 23-Ноя-23, (184)
Поэтому никакой битврот вы получить не можете Если вдруг ошибка пройдёт ECC, вер, Tron is Whistling (?), 23:37 , 23-Ноя-23, (191)

ECC пропускает ошибки с вероятностью, которая на больших системах или при длите, fidoman (ok), 15:59 , 23-Ноя-23, (114) +1 //

Чего Чтобы ECC современного накопителя пропустил ошибку - надо очень постаратьс, Tron is Whistling (?), 23:05 , 23-Ноя-23, (185)

Агаблин, а у меня есть текучая флеха где EXT4 за месяц - в труху Наверное это м, Аноним (-), 02:26 , 24-Ноя-23, (221) –3

Странно как-то, у накопителей свои ECC , но вот параметр BER для накопителей те, аНОНИМ (?), 17:36 , 23-Ноя-23, (141) +1 //

Звон-то вы слышали Хоть бы потрудились сами почитать, что запостили Начнём с B, Tron is Whistling (?), 23:19 , 23-Ноя-23, (186)

Почему ныне не приводят BER Цифирь слишком неприглядная При штатном чтении мно, Tron is Whistling (?), 23:19 , 23-Ноя-23, (187)
Тут правда я одну вещь не упомянул Наличие NCER не значит, что сектор не прочита, Tron is Whistling (?), 23:32 , 23-Ноя-23, (190) +1

Вообще-то как раз и значит, иначе бы его маркетолухи не назвали бы NON -correc, аНОНИМ (?), 09:15 , 24-Ноя-23, (230)

Для начала давай ещё раз поясню, что такое NCER в этом контексте NCER - это зна, Tron is Whistling (?), 09:41 , 24-Ноя-23, (232)

Это ниоткуда не следует И в даташите не написано Значит -- не факт и я имею пр, аНОНИМ (?), 12:23 , 24-Ноя-23, (254)

Можешь предполагать чего угодно Если данные действительно ценные - надо совсем н, Tron is Whistling (?), 22:01 , 24-Ноя-23, (294)

Чувак, у меня есть тупо сыпучая флеха юзаемая как стресстест, где BER весьма и, Аноним (-), 02:28 , 24-Ноя-23, (222)

То, что у тебя есть сыпучее китайское говно - это не значит, что его надо в серь, Tron is Whistling (?), 09:43 , 24-Ноя-23, (233)

Да вот знаете, чексуммы очень помогают понять что реально подсунули и как это ре, Аноним (319), 02:02 , 26-Ноя-23, (327)

Улавливаю Жопоруки даже 1e-16 ниасилили Это утверждение нуждается в доказательс, аНОНИМ (?), 09:14 , 24-Ноя-23, (229)

1e-15 - это было очень много на те же терабайтные драйвы в 3-4 болвашки Объёмы в, Tron is Whistling (?), 09:46 , 24-Ноя-23, (234)

К сожалению - нет Всё, что смогла поймать ЕСС, она исправила Эта ошибка - наст, Аноним (297), 22:44 , 24-Ноя-23, (297)

Вообще-то да, но продолжайте верить в булшит , Tron is Whistling (?), 23:17 , 24-Ноя-23, (299)

в безошибочность ЕСС , Аноним (297), 16:04 , 25-Ноя-23, (314)

Обычно алгоритм ECC ловит немножко больше, чем способен исправить , Tron is Whistling (?), 22:39 , 25-Ноя-23, (317)

1 Сила FEC в роли абстрактной чексуммы совершенно не обязана быть чем-то этак, Аноним (319), 05:19 , 26-Ноя-23, (328)

Про объём уже писал, на современных хардах лет много уже ECC может добавлять п, Tron is Whistling (?), 11:54 , 26-Ноя-23, (329)

Раньше был еще более приличным - в процентном соотношении В частности 4K сектор, Аноним (319), 02:18 , 27-Ноя-23, (357)

И да, 2 256 - это всего-то ничего, 32 байта Объём современных ECC на сектор неск, Tron is Whistling (?), 11:57 , 26-Ноя-23, (330)

И тем не менее, это совершенно астрономическое число Даже 2 128 попыток обломно, Аноним (319), 02:01 , 27-Ноя-23, (356)

Вы про китайский хлам или что Так-то нормальные производители FEC берут с хорош, Tron is Whistling (?), 14:10 , 27-Ноя-23, (371)
А нормальные производители - это кто А то если взять допустим самсунь - у них н, Аноним (319), 21:16 , 27-Ноя-23, (373)

Ну смотри - пока ты искал битвротики в ECC - твоя ZFS тебе незаметно порола данн, Tron is Whistling (?), 12:08 , 26-Ноя-23, (333)

И вот конкретно поэтому лучше выбирать простые как доска стеки - ECC накопителя,, Tron is Whistling (?), 12:21 , 26-Ноя-23, (335)

Глядя на количество юзеров которым энтерпрайзне SSD вынесли ЭТО внезапным роялем, Аноним (319), 02:20 , 27-Ноя-23, (358)

тебе решение для локалхоста или данные хранить Для второго другое - не-open s, пох. (?), 14:16 , 23-Ноя-23, (73) +1 //

В смысле, ты даже не читал статьи на тему того, зачем вообще контрольные суммы в, fidoman (ok), 15:55 , 23-Ноя-23, (111) –2 //

Это как правило диски под линейную циклическую видеозапись, зачем вы их такие бе, Tron is Whistling (?), 23:21 , 23-Ноя-23, (188)

причем прошлого десятилетия Я не слышал о подобных проблемах у пресловутых wd p, нах. (?), 13:40 , 24-Ноя-23, (265)

Это вообще - unspecified Фирмвара что хочет - то и делает Нет никаких требован, Аноним (-), 02:32 , 24-Ноя-23, (223) +1

RAID 5 6 и не надо быть в курсе - и вменяемые контроллеры делают проверку при ре, Tron is Whistling (?), 09:51 , 24-Ноя-23, (236) –1

В любом случае подобные диски и данные, которые жалко - это неюзабельный кейс, к, Tron is Whistling (?), 09:52 , 24-Ноя-23, (237) +1
У меня другие идеи на этот счет С чексуммами соотношения явно лучше, при том до, Аноним (319), 02:35 , 27-Ноя-23, (359)

Я тут уже пару раз писал, и в третий тебе напишу за 15 лет ни одного обращения , Tron is Whistling (?), 10:04 , 27-Ноя-23, (366)

Вы ни разу не ответили мне на 1 простой вопрос - как вы вообще проверяли целостн, Аноним (319), 21:25 , 27-Ноя-23, (374)

Ничего гугл не собрал Вы их самодельные тазики, которые сервис, а не no-problem, Tron is Whistling (?), 23:08 , 27-Ноя-23, (375)

Вы не понимаете хотя это нормально, когда уровень обсуждаемого превышает способ, Аноним (-), 04:12 , 28-Ноя-23, (377)

Вы просто не понимаете, что это целый комплекс мер Распределённые структуры очен, Tron is Whistling (?), 09:27 , 28-Ноя-23, (383)

На мой вкус - сперва извольте ответить на вон тот простой вопрос, как вы вообще , Аноним (-), 15:50 , 28-Ноя-23, (388) –1
Недорого и круто - это вообще не про гугл Следует Накладные расходы на распарал, Tron is Whistling (?), 21:24 , 28-Ноя-23, (393)
Это квинтэссенция гугл Одна из вещей которые конкурентам нечем крыть - они не п, Аноним (390), 22:34 , 28-Ноя-23, (398)
Да, пока оно в пустоту пишется, инопланетяне сидят и строят индексы Ничего не из, Tron is Whistling (?), 09:38 , 29-Ноя-23, (403)
В распределёнках самое интересное начинается именно тогда, когда НЕ совпал Вот т, Tron is Whistling (?), 21:37 , 01-Дек-23, (409)

казалось бы - очевидно, что - вернуть ошибку чтения, а не произвольные данные с , пох. (?), 19:38 , 24-Ноя-23, (287)

Не, такая серия у сигейта действительно была Video-only Этот треш действительн, Tron is Whistling (?), 22:03 , 24-Ноя-23, (295)

Названия модели или серии так и нет, зато есть обобщение на все диски под видео , Аноним (309), 12:45 , 25-Ноя-23, (310) –1

да какая разница все равно ты в розницу это чудо не купишь Что-то специфичное , пох. (?), 17:07 , 26-Ноя-23, (346)

А вот это - да, верно , Tron is Whistling (?), 22:49 , 26-Ноя-23, (351)

А кто его знает что в голове у тех разработчиков фирмварей Они решили делать во, Аноним (319), 03:07 , 27-Ноя-23, (361)

Как ЖЫ ТАК А вот эта вся сквозная целостность феерическая Чексуммы на каждый ч, Tron is Whistling (?), 14:02 , 23-Ноя-23, (60) +2 //

ну не торопись - мы же можем еще и наоборот - неправильно посчитать сумму правил, нах. (?), 11:31 , 24-Ноя-23, (249) +1

ext4 - самая стабильная и надежная если хранить файлыxfs - кончается место - дан, Аноним (69), 14:12 , 23-Ноя-23, (69) –2 //

С ext4 без трёх бекапных копий вообще работать невозможно Да ещё и 12309 донима, Аноним (82), 14:18 , 23-Ноя-23, (76) –3
Но ты ufs2 в глаза не видел, особо сказать ничего не можешь, но всё же говоришь , Аноним (153), 14:20 , 23-Ноя-23, (78) +2
ZFS убить ппц как сложно, видел только при откровенно дохлом БП, когда диски на , fidoman (ok), 16:08 , 23-Ноя-23, (118) +1 //

Вот в этой новости - оно самоубивается До состояния не вытащить никак Ну, то, Tron is Whistling (?), 23:40 , 23-Ноя-23, (192) +1 //

С практической точки хрения, если у вас даже и убилась копия копии файла - это, , Аноним (-), 19:11 , 28-Ноя-23, (389)

Какой богатый опыт И как же вы с такими руками еще EXT4 не сломали , OpenEcho (?), 16:26 , 23-Ноя-23, (123) //

а как он ее сломает если в его винде - ntfs Богатый опыт у него - чтения разной, нах. (?), 11:32 , 24-Ноя-23, (250) +1

Самое прикольное за кадром осталось Во-первых, обнаружить файлы, ссылающиеся на , Tron is Whistling (?), 14:16 , 23-Ноя-23, (74) +1 //

fsck же для трусов zfs без него обойдется, так все бандерлоги говорят и потому , пох. (?), 14:21 , 23-Ноя-23, (81) //

Руководство по администрированию файловых систем ZFS Solaris 8226 Октябрь 200, Аноним (269), 14:31 , 24-Ноя-23, (271) //

оно ж точно по-русски было написано Т е васяны цитируют машинный перевод юзерг, пох. (?), 17:04 , 26-Ноя-23, (345)

Не понял юмора Цитата из PDF на русском с сайта Оракла , Аноним (269), 13:48 , 01-Дек-23, (407)

Ну и Машиннопереведенная чушь Вас удивляет что она оказалась на сайте оракла , пох. (?), 17:44 , 01-Дек-23, (408)

С линуксовыми такая ж фигня Пока что-то разваливаться не начнёт, хрен поймаешь , Аноним (82), 14:25 , 23-Ноя-23, (85) –1

Такое ощущение, что тут уже линуксоидов не осталось, только представители маркет, Аноним (82), 14:16 , 23-Ноя-23, (75) +2
ext4 gang reporting in, Аноним (86), 14:23 , 23-Ноя-23, (84) +1 //

Да, расскажите как вы определяете что данные вообще не побились Технологией , Аноним (319), 03:12 , 27-Ноя-23, (362)

ext2 для ноутбуков, для остального есть ext4, bazanul (?), 14:34 , 23-Ноя-23, (91)
EXT а дети пусть балуются чем хотят , Аноним (96), 14:51 , 23-Ноя-23, (97) +2
если кто-то выключает sync, checksum, брезгует пользоваться хотя бы раз в неделю, Мурат (?), 16:09 , 23-Ноя-23, (119) –2 //

Ни первое, ни второе, ни третье - от описанной х ты не помогут , Tron is Whistling (?), 23:23 , 23-Ноя-23, (189) +2

дедуп говорили они, спасибо поржал , Sw00p aka Jerom (?), 16:41 , 23-Ноя-23, (124) //

А получился - debug, да еще в авральном порядке после релиза Бывают в жизни ого, Аноним (-), 02:36 , 24-Ноя-23, (224) –1 //

Пруф то будет Или у тебя обычные 294е об ратушки Перепутал проблему mbr диска б, Аноним (282), 18:26 , 24-Ноя-23, (282) //

Я честно говоря не помню всех деталей - это было в районе XP 2003 чтоли, когда д, Аноним (319), 02:54 , 27-Ноя-23, (360)

То что не помнишь прямо совершенно тебе не мешает с диким апломбом нести ересь 2, Аноним (406), 06:58 , 30-Ноя-23, (406)

В FreeBSD 14-RELEASE по дефолту vfs zfs bclone_enabled 0Так что, расходимся А л, Аноним (127), 16:44 , 23-Ноя-23, (127) //

Тут же пишут, что ашипка непонятно где, и может вылезти даже если bclone выключе, 1 (??), 17:56 , 23-Ноя-23, (147) +1

В качестве рекомендованного обходного пути блокирования ошибки предложено не уст, 1 (??), 17:02 , 23-Ноя-23, (128) //

Лучший ответ , Аноним (143), 17:46 , 23-Ноя-23, (143) +1
Жаль, что не питон , Аноним (153), 19:25 , 23-Ноя-23, (163) +1
Смеяться будем, когда гентушники локализуют проблему У меня такое же было с ext, Аноним (269), 14:38 , 24-Ноя-23, (272) //

А вот горе оверклокер-андерклокер узнал почему свои лапки не стоит совать в DVFS, Аноним (390), 19:44 , 28-Ноя-23, (391) //

А вот и очередной эксперт включил механическую психзащиту, не улавливая, к чему , Аноним (269), 12:20 , 29-Ноя-23, (404)

ZFS обретает популярнось, и это хорошо Работайте, братья , Аноним (144), 17:48 , 23-Ноя-23, (144) +3
В FreeBSD 13 2 с последними патчами проблема воспроизводится Временный фикс sysc, А.Н.Оним (?), 10:16 , 24-Ноя-23, (242) +2 //

Ну вот очень похоже что таки дело совсем не в bclone bsd only фикс Потому что э, нах. (?), 11:34 , 24-Ноя-23, (251) +1 //

Скрыто модератором, А.Н.Оним (?), 12:04 , 24-Ноя-23, (253) //

Скрыто модератором, нах. (?), 12:58 , 24-Ноя-23, (258)

2 чая Ну хоть пошла техническая инфа , 1 (??), 12:02 , 24-Ноя-23, (252) //

где инфа-то Шаманские песни пошли , нах. (?), 12:59 , 24-Ноя-23, (259) //

Ну есть немного Зато рекомендации -1 Не апгрейдить пул2 Если проапгрейдил -, 1 (??), 13:48 , 24-Ноя-23, (268)

вот это - хорошая рекомендация, всегда ей следую - тут главное - чтоб какая-н, пох. (?), 19:24 , 24-Ноя-23, (285)

Проверил пул на проблемной системе на наличие файлов, полностью или частично то, А.Н.Оним (?), 04:11 , 25-Ноя-23, (302) //

Сделали простой скрипт для поиска потенциально битых файлов на zfs https githu, Аноним (312), 13:37 , 25-Ноя-23, (312) +1 //

ну так себе идея считать потенциально битым любой файл с 4k нулей У меню их ест, нах. (?), 20:30 , 26-Ноя-23, (350)

Выпустили исправление OpenZFShttps github com openzfs zfs pull 15571, Аноним (312), 13:35 , 25-Ноя-23, (311) +1 //

это нужно но не то исправление Увы , пох. (?), 17:01 , 26-Ноя-23, (343) //

Или таки то похоже, reproducer sh больше не работает после этого патча Там на, пох. (?), 23:30 , 26-Ноя-23, (353) +1

Весёлая история То есть оно ещё и с bclone вообще не связано, просто вся такая , Tron is Whistling (?), 12:04 , 26-Ноя-23, (331) –1 //

Особо забавно было, как тонны верующих хвалились везде непревзойдённой надёжност, Tron is Whistling (?), 12:07 , 26-Ноя-23, (332) –1 //

Вот этот дизайн тоже не очень In general inodes and offsets start from 0 and wo, Аноним (336), 14:21 , 26-Ноя-23, (336) +1 //

Кросивое , пох. (?), 17:02 , 26-Ноя-23, (344)

ну вообще-то нет Такие баги которые портят данные и при этом висят необнаруженн, пох. (?), 17:00 , 26-Ноя-23, (342)

Ну и вкратце реальный источник ошибки - успехов местным васянам найти его git b, пох. (?), 23:55 , 26-Ноя-23, (354) +3 //

Шикарно Детектив, а не добавите эти детали с подробностями расследованоя в ново, Аноним (319), 03:20 , 27-Ноя-23, (363) //

с этим обращайтесь к администрации сайта Но она и так неплохо живет, незачем но, нах. (?), 12:43 , 27-Ноя-23, (369) //

В принципе ты и сам можешь отредактировать, если яваскрипт отсюда выполнять не о, Аноним (380), 04:34 , 28-Ноя-23, (380)

так оно ж премодерируется Т е точно так же сиди и жди пока пчьолы прилетят , пох. (?), 17:07 , 29-Ноя-23, (405)

Да, тут 146 можно обгитблеймится что-то найти Вполне возможно, что связка неско, Tron is Whistling (?), 10:10 , 27-Ноя-23, (367) //

там раза четыре этот код ковыряли и это помимо глобальной переделки в open верс, нах. (?), 12:48 , 27-Ноя-23, (370)

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

53. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от fidoman (ok), 23-Ноя-23, 13:45

Выкинуть бы всё это "творчество", но проблема только в том, что другого решения для raid5/raid6 с хешами для проверки целостности данных на дисках в общем-то и нет, а обнуление секторов или просто их порча даже при не особо большом объёме данных происходят регулярно...

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

62. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –1 +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:03

Чего, простите?
RAID5/6 собственно и позволяет проверить целостность...

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

112. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от fidoman (ok), 23-Ноя-23, 15:58

> Чего, простите?
> RAID5/6 собственно и позволяет проверить целостность...
RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.

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

139. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от аНОНИМ (?), 23-Ноя-23, 17:31

> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.
А вот RAID6 теоретически позволяет (если битые данные на одном диске из всех), но опять же нихрена такого mdraid не делает. Я проверял.

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

226. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (-), 24-Ноя-23, 03:12

>> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.
> А вот RAID6 теоретически позволяет (если битые данные на одном диске из
> всех), но опять же нихрена такого mdraid не делает. Я проверял.
А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает. Выглядит как потрошеный окунь в живой воде у стругацких, но при всем этом - еще и работает. Крутануть теорвер в свою пользу - по своему забавно.

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

228. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от аНОНИМ (?), 24-Ноя-23, 09:09

> А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает.
На бтрфс с миррорами -- работает. С раид5-6 когда я проверял (довольно давно) -- НЕ работало. Отдавало примерно половину файлов или меньше, остальные io error. А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало.

Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom of=/весь/девайс/из/рейда и монтировал ФС взад. ZFS усралось спамить в dmesg, но всё железобетонно отдало. А после скруба стало как новое. btrfs с raid5/6 обломался.
Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде.

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

323. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 26-Ноя-23, 01:16

>> А на btrfs такое даже работает, я для RAID1 и DUP проверял
> На бтрфс с миррорами -- работает.
А я умею читать документацию, и если нечто озвучено как экспериментальная фича - ну я и делаю определенные выводы.
Впрочем - там можно и более продвинуто. Скажем если метаданные RAID1 (или даже RAID1C3 для фанатов RAID6) а данные RAID5/6 - это уже более интересное комбо. Потому что write hole перестает импактить метаданные, а остальное - все же менее проблемный топик. Если метаданные живые, все намного оптимистичнее в плане перспектив.
На самом деле write hole там можно аннулировать scrub после краха, но это неудобное требование. Более полное решение требует изменение структур ФС для логинга write intent и все такое.
> С раид5-6 когда я проверял (довольно > давно) -- НЕ работало.
> Отдавало примерно половину файлов или меньше, остальные io error.
RAID5 таки довольно заметно пофиксили - хоть и ценой потери перфоманса в ряде операций, ибо полный RMW страйпа делается чаще. В паре с RAID1 для метаданных, можно уже даже попробовать потрепыхаться. Но официально все равно experimental, и если что - ну, девы честно сказали как оно. Мне честное описание свойств - больше нравится чем красивые сказки. Меньше неприятных сюрпризов. Больше места для информированных осознанных решений.
> А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало.
Да вот судя по новости, с дополнениями, где вообще рефлинки, кажется, амнистировали - но теперь вообще "хрен бы его знает что это и где" - потому что походу накрывает и старые корутилсы, и более лохматые версии без рефлинков, там целая детективная история, где встречаются джамшуты месившие хз что, паленые материалы, и пара обрушившихся зданий, после чего и стали изучать что за фигня такая с этим железобетоном.
> Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom
> of=/весь/девайс/из/рейда и монтировал ФС взад.
> ZFS усралось спамить в dmesg, но всё железобетонно отдало.
> А после скруба стало как новое. btrfs с raid5/6 обломался.
Ну вон то какой-то не особо реалистичный случай отказа. Чему в реальном мире ЭТО соответствует?
> Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде.
Могло на слет супера обидиться еще. Но в таком случае вы всяко ребилд девайса по всей площади делать будете, плюс-минус передобавка девайса чтобы супер нарезать
Более того - я не совсем понимаю как идентифицировать девайс без супера как свой. По буковкам? Это достаточно чревато, ща линукскернель оборудованеи асинхронно инициализирует, буковки - ну вот не обязаны мировой константой быть.
У вас - ну вы все 3 копии супера вынесли. В реальных сценариях, от них или что-то останется, или это полный отказ и замена девайса с полным ребилдом соответственно. Разработчики btrfs все же на реалистичные сценарии ориентировались. А как там какая тушка с оторваной головой бегает - ну, не очень интересно, имхо. Интереснее чтобы с типовыми факапами железа справлялось.
И в этом смысле - накопителей подсирающих трухой в секторах сейчас заметно прибавилось например. Я не спорю что вон то забавные тест, но он не соответствует ни одному из real workd сценариев отказа сторажей которые я видел.

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

168. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (165), 23-Ноя-23, 19:44

Я смотрю ты шаришь. Не объяснишь по простому, что такое write gap у RAID5/6?

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

182. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 22:58

Не объясню - это ошибочный термин.

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

183. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:00

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

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

204. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от Аноним (204), 24-Ноя-23, 01:04

Тогда мне поясни за wright hole.

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

63. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:04

Если у вас порча секторов происходит регулярно - есть смысл посмотреть в сторону стабильности платформы, скорее всего данные теряются до записи на диск.
Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор не может.

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

110. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –3 +/–

Сообщение от fidoman (ok), 23-Ноя-23, 15:49

> Если у вас порча секторов происходит регулярно - есть смысл посмотреть в
> сторону стабильности платформы, скорее всего данные теряются до записи на диск.
> Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор
> не может.
google:bitrot

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

184. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:03

Плджад. Там ECC. Причём на современных накопителях - не обязательно одноуровневый даже.

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

191. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:37

Поэтому никакой битврот вы получить не можете.
Если вдруг ошибка пройдёт ECC, вероятность чего запредельно мала - вы вместо данных в секторе (512 байт или целых 4К ныне) получите кашу, потому что наборов данных, подходящих под один и тот же "хеш" ECC (там конечно не хеш, там многомерные поля, но не будем об этом) - не много.

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

114. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от fidoman (ok), 23-Ноя-23, 15:59

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

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

185. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:05

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

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

221. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –3 +/–

Сообщение от Аноним (-), 24-Ноя-23, 02:26

> Чего? Чтобы ECC современного накопителя пропустил ошибку - надо очень постараться.
Агаблин, а у меня есть текучая флеха где EXT4 за месяц - в труху. Наверное это мой глюк? Не, IO Error эта пакость наверх не репортит. Просто грузит труху периодически.
Btrfs в схеме DUP - даже на таком живет. Заодно позволяя измерить частоту факапов. На этом экземпляре - если записать, через недельку scrub налетит на 10-20 секторов которые разъехались по чексумам. И это тебя жестко оспаривает. Стараться там вообще не надо, надо записать эн гигз, а потом через недельку scrub запустить и получить свои чексум ерроры. Просто как топор, воспроизводимо.
> Современные HDD и SSD вообще только благодаря ECC можно сказать и работают,
А если еще и изучить математику за ECC - можно узнать что эти алгоритмы имеют заметно отличную от ноля вероятность посчитать блок за исправный, хотя там труха. При достаточном числе read errors и большом числе попыток в какой-то момент вы таки можете и выиграть в эту лотерею. А экстремальный случай мне вот за счет btrfs'а "отфильтровался" под внимание.
> если чисто гипотетически убрать ECC - их использовать будет вообще толком
> невозможно.
А чисто практически - накопители, особенно флешовые, имеют манеру выгружать какой-то крап, далеко не всегда утруждая себя репортом IO Error при этом.
> Ещё раз повторюсь: если у вас это возникает регулярно - смотрите в
> район платформы, а не накопителя.
Повылезло тут экспертов мля со своими EXT4 и XFS, измерявшим разрушения хз как, видимо теориями. А таки - чексумы в ФС - отличная штука. И ZFSники в этом были правы.

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

141. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от аНОНИМ (?), 23-Ноя-23, 17:36

> Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор не может.
Странно как-то, "у накопителей свои ECC", но вот параметр BER для накопителей тем не менее приводят: https://documents.westerndigital.com/content/dam/doc-library... (1 ошибка на 10^15 бит). И если его пересчитать в терабайты прочитанного, это будет всего-то сотня терабайт. Откуда сразу следует вывод, что хранить данные на raidz1/raidz2, где каждый блок на каждом диске защищён отдельной чексуммой -- есть смысл.
А кому собственные данные не важны -- ну те ext4 пользуются, вон как диванные эксперты вокруг.

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

186. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:19

Звон-то вы слышали...
Хоть бы потрудились сами почитать, что запостили.
Начнём с BER.
BER - оно и есть приблизительная оценка частоты срабатывания ECC в обычных условиях работы, без повреждений накопителя. Как часто будет возникать ошибка ECC при чтении в штатных условиях. Я выше написал: если бы не ECC - да, накопителями бы вообще пользоваться невозможно было.
Теперь к вашим баранам.
В том, что вами приведено - это не BER. Это NCER. Non-correctable (там non-recoverable) error ratio.
Это количество бит, среднее, прочитанных, после которого вы получите неисправимый сбойный сектор.
Не 1 на 10^15, а <1 на 10^15. Разницу улавливаете?
Менее одной неисправимой битовой ошибки на 125 прочитанных терабайт. Эту ошибку поймает та самая ECC, и выдаст как нечитаемый сектор. К сожалению да, для современных накопителей в десяток и более ТБ - этот параметр неизмеримо мал. Их только в рейд и ставить.
ECC false positive ratio же на несколько порядков меньше, данные ECC в современных хардах запросто могут весить ~10% и больше от сектора, плюс как правило многоуровневая ECC - одна в коде записи и другая в записываемых данных. А у более надёжных драйвов ещё и цикл WRV бывает добавлен, но это уже детали.

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

187. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:19

Почему ныне не приводят BER? Цифирь слишком неприглядная. При штатном чтении многобитовая ошибка - норма жизни. Особенно на черепичках.

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

190. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:32

Тут правда я одну вещь не упомянул.
Наличие NCER не значит, что сектор не прочитается хостом вообще совсем никак. Сначала диск попробует перечитать, первые ошибки при отсутствии серьёзного повреждения магнитного слоя обычно статистически не значимы.
Далее оно со 2-3-5-10 попытки скорее всего прочитается. И когда прочитается - сектор будет стёрт и испробован на запись. Если после испробования сектор не пройдёт по числу битовых ошибок в той самой ECC - будет отправлен в другое место диска, получите ремап. На черепичках может быть так лёгкой рукой смахнута в другое место целая группа секторов. Всё это незаметно для хоста, естественно.
То есть само по себе NCER ещё не фатал. Реальную ошибку вы получите только если операция чтения свалится в совсем никак, даже после пары перепозиционирований голов. Диски под рейд настроены делать меньше попыток, диски под бытовуху - больше.
Но тем не менее, средние 125 Тб на 22 Тб хард - это запредельно мало. О времена, о нравы.
---
Диски под видео - отдельный экземпляр, их здесь где-то ниже упомянули - вот эти да, страшное дело - могут просто смахнуть сектор и сделать вид, что прочиталась фигня. Эти диски лучше никуда больше не ставить.

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

230. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от аНОНИМ (?), 24-Ноя-23, 09:15

> Наличие NCER не значит
Вообще-то как раз и значит, иначе бы его маркетолухи не назвали бы "*NON*-correctable"

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

232. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:41

Для начала давай ещё раз поясню, что такое NCER в этом контексте. NCER - это значит, что сектор с первого раза корректно прочитать не удалось. Не просто ECC отработала (это BER, точнее не совсем BER, но опустим), а ECC сказала, что всё, задница. Но это не значит, что его не удастся прочитать со 2 захода например.

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

254. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от аНОНИМ (?), 24-Ноя-23, 12:23

> Но это не значит, что его не удастся прочитать со 2 захода например
Это ниоткуда не следует. И в даташите не написано. Значит -- не факт и я имею право предполагать худшее. Речь-то о моих данных.
Примеры обратного были тут где-то рядом.

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

294. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 22:01

Можешь предполагать чего угодно.
Если данные действительно ценные - надо совсем не ZFS обвешиваться.
И порядок денег там будет совершенно другой.

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

222. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (-), 24-Ноя-23, 02:28

> BER - оно и есть приблизительная оценка частоты срабатывания ECC в обычных
> условиях работы, без повреждений накопителя. Как часто будет возникать ошибка ECC
> при чтении в штатных условиях. Я выше написал: если бы не
> ECC - да, накопителями бы вообще пользоваться невозможно было.
Чувак, у меня есть тупо сыпучая флеха юзаемая как стресстест, где "BER" весьма измеримый, без специальных усилий. И весь твой спич на этом фоне можно назвать бесполезным теоретическим булшитом не стоящим байтов истраченых на него.

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

233. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:43

То, что у тебя есть сыпучее китайское говно - это не значит, что его надо в серьёзном проде использовать.
Ну, ты - можешь.
И да, то, что ты видишь - далеко не BER.
Это NC + ECC false positive. В китайских поделках встречается очень часто, поэтому что на ECC тоже экономят.

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

327. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 26-Ноя-23, 02:02

> То, что у тебя есть сыпучее китайское говно - это не значит,
> что его надо в серьёзном проде использовать.
Да вот знаете, чексуммы очень помогают понять что реально подсунули и как это реально работает. Вместо выслушивания голимых теорий высосаных из пальца.
Не нравится флеха? А я и дофига кейсов с энтерпрайзными SSD видел на эту тему. Особенно эффективно получается если его как bcache оформить. И тут то и оказалось что вместо того чтобы сразу и круто помереть - оно при приближении к окончанию ресурса может начать гадить битыми блоками вместо этого. Без всяких IO error. А файлухи на это все реагируют... довольно интересно, скажем так.
При том у фанов XFS/EXT4, это вообше как-то так: на них совершенно ВНЕЗАПНО сверху падает рояль и зашибает их до дырки в асфальте. А потом оказывается что осыпающийся девайс гадил, так то, давно - но без чексум это не видно, а развалилось когда уже живого места в ФС нет. XFSники о чем-то даже догадываются и - вон - пыжатся scrub прикрутить. Получается не очень, но почему-то все это идет вразрез с вашими теориями. Btrfs'ники - вот - за счет чексум - такие плюхи ловили на подлете. В отличие от вон тех счастливчиков.
> Ну, ты - можешь. И да, то, что ты видишь - далеко не BER.
Естественно. Это уже то что за FEC пролезло.
> Это NC + ECC false positive. В китайских поделках встречается
> очень часто, поэтому что на ECC тоже экономят.
Да оно и на энтерпрайзных SSD случается, любители bcache не дадут соврать. Один из аргументов за нормальную интеграцию иерархического кеширования в ФС, там в таких случаях виднее реальное состояние кусков VS запрошенная схема избыточности.

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

229. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от аНОНИМ (?), 24-Ноя-23, 09:14

> Не 1 на 10^15, а <1 на 10^15. Разницу улавливаете?
Улавливаю. Жопоруки даже 1e-16 ниасилили.
> и выдаст как нечитаемый сектор.
Это утверждение нуждается в доказательства.
> ECC false positive ratio же на несколько порядков меньше
И это -- тоже. Ну вот прям для конкретного жопоруками сделанного накопителя.

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

234. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:46

> Улавливаю. Жопоруки даже 1e-16 ниасилили.
1e-15 - это было очень много на те же терабайтные драйвы в 3-4 болвашки.
Объёмы выросли, а частота возникновения ошибок не уменьшилась.
По идее со всем этим ростом размера ECC / улучшения алгоритмов - должно было бы быть лучше, но всё это "съелось" тем, что уменьшился размер ячейки записи + при записи внахлёст, которая обычно используется, всё реально очень плохо.
Всё остальное - беллетристика.

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

297. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (297), 24-Ноя-23, 22:44

> Эту ошибку поймает та самая ECC, и выдаст как нечитаемый сектор
К сожалению - нет. Всё, что смогла поймать ЕСС, она исправила. Эта ошибка - настоящая, никто её не заметил. Вы получаете блок, в котором ошибка. При больших объёмах вероятность ошибок становится существенной. Поэтому - только контрольные суммы, RAIDZ1/2/3, правильные серверные диски, которые при записи проверяют,что блок записался правильно. Т.е. просто бэкапы тут не помогут, разве что делать несколько и сравнивать их между собой, выбирая ошибки вручную. Получая в процессе записи-чтения бэкапов новые ошибки :)

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

299. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 23:17

Вообще-то да, но продолжайте верить в булшит.

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

314. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (297), 25-Ноя-23, 16:04

> продолжайте верить
в безошибочность ЕСС :)

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

317. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 25-Ноя-23, 22:39

Обычно алгоритм ECC ловит немножко больше, чем способен исправить.

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

328. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 26-Ноя-23, 05:19

> Обычно алгоритм ECC ловит немножко больше, чем способен исправить.
1) Сила FEC в роли абстрактной "чексуммы" совершенно не обязана быть чем-то этаким. Это вообще ниоткуда не следует. Например, насколько я помню, ReedSolomon(223,255) может исправить до 16 байтов на (223 данных + 32 парити), или до 32, если известно где ошибки. Но вот как "generic" чексумма бомбардируемая рандомом он может пропустить абсолютный левак как сошедшееся решение с вероятностью сравнимой с 40-битным CRC, чтоли, насколько я помню оценки (лучше перепроверить). В любом случае - вероятность пропуска левака там крайне далековата от 2^128 и тем более 2^256.
Уход в конские плотности записи для HDD и всякие QLC для флеша - BER разумеется не улучшили.
2) FEC занимает место. И портит циферки в маркетинге, сжирая место под техническое добро которое юзер в заявляемой емкости не видит, а вот производителю за это место заплатить придется. Поэтому его корректирующие возможности разумеется делают по минимуму, необходимому для более-менее беспроблемной работы в гарантийный период, чтобы хранить минимум избыточности. Все остальное - от лукавого. А так чтобы вот прямо ломовой запас, "в космос летим" - только за космические цены. В остальных случаях - на минималках, поэтому уход в стресстестирование этой штуки запросто приведет к отгрузке левака.

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

329. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 26-Ноя-23, 11:54

Про объём уже писал, на современных хардах (лет много уже) ECC может добавлять приличный объём к данным.
Более того, в современных HDD минимум два уровня избыточности. Одно - как раз таки линейное кодирование записи, которое можно назвать FEC. Второе ныне - привычное уже многосекторное (обычно трековое) кодирование через интерливер, очень похожее на то, что применялось и применяется на оптических дисках. На RAID-адаптированных, да и не только, бывает плюсом к линейному FEC ещё вторичный посекторный код. На черепичках бывает ещё многоуровневый интерлив.
Поэтому "левак" вы скорее всего получите уже в платформе, нежели с диска.

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

357. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 02:18

> Про объём уже писал, на современных хардах (лет много уже) ECC может
> добавлять приличный объём к данным.
Раньше был еще более приличным - в процентном соотношении. В частности 4K сектора вместо 512 насколько я помню делали как раз чтобы улучшить соотношение данные-FEC. На более длинном блоке соотношения могут быть более удачные в плане корректирующей способности VS какой это процент от данных займет. Ну как, сектора должны быть более-менее независимо декодабельны - иначе на запись сектора придется ворочать всю группу а это сложно и хреново. А на 512 байтах - даже небольшая добавка становится заметным % от этого, при умеренной корректирующей способности.
> Более того, в современных HDD минимум два уровня избыточности. Одно - как
> раз таки линейное кодирование записи, которое можно назвать FEC.
> торое ныне - привычное уже многосекторное (обычно трековое) кодирование через
> интерливер, очень похожее на то, что применялось и применяется на оптических дисках.
Идеи interleaving известны давно. Но они хорошо работают в основном от нечитаемости длинного сегмента (типа царапины на оптическом диске). Где этот сегмент превысил бы корректирующие возможности "наивного" 1-уровневого варианта, так размазал проблему на эн субблоков, масштаб проблемы небольшой для каждого субблока и вложенный FEC справляется.
А если траблы вместо этого больше напоминают "осыпон по всей площади" - ну, упс, deinterleave от этого уже сильно меньше поможет и соотношения уже не такие прикольные.
> На RAID-адаптированных, да и не только, бывает плюсом к линейному FEC ещё
> вторичный посекторный код.
RAID адаптированные - в основном так принципиально - отличаются фирмварью, чтобы не уходить надолго в себя "хоть там что", что считается контроллером за отказ девайса и ведет к залету на ребилд райда. Более обычный девайс предпочтет долбиться в нечитаемый сектор намного дольше. И если посмтреть что при этом случается - линух через секунд 15 мучений таймаутит это, пытается reset, retry операции и проч. В зависимости как сложатся пятна на солнце - это может выпасть в крайне неудачное взаимодействие. Которое надолго вклинит IO приведет к считанию девайса выпавшим. В любом случае система потребует мануального внимания и это уже булшит.
> На черепичках бывает ещё многоуровневый интерлив. Поэтому "левак" вы скорее всего
> получите уже в платформе, нежели с диска.
HDD и правда грузят левак скорее как исключение чем правило. А вот SSD, даже энтерпрайзные, прикалываются только в путь. И в каком QLC - сыпется по всей площади, ну и какой особый профит от деинтерлива ожидается? Если много утекло, что так UNC, что сяк, как ни крути. И вопрос сводится в основном к тому какой % площади готовы пожертвовать на FEC в результате.

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

330. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 26-Ноя-23, 11:57

И да, 2^256 - это всего-то ничего, 32 байта.
Объём современных ECC на сектор несколько выше, да и на входе интерливера бит очень много.
Получить коллизию внутри сектора в нескольких алгоритмах одновременно с такой длиной, при корректности соседних данных - это надо очень постараться.
Одна из причин, по которой из маркетинга исчезло понятие BER и появилось NCER, кстати.

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

356. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 02:01

> И да, 2^256 - это всего-то ничего, 32 байта.
И тем не менее, это совершенно астрономическое число. Даже 2^128 попыток обломно делать. А то в 2^128 раз больше 2^128. В вселенной энергии на столько попыток нет, так что можно не париться. Если бы это было правдой. Но увы... FEC не криптографические чексумы, не на это оптимизированы.
> Объём современных ECC на сектор несколько выше,
Их корректирующие способности - и вероятность что левак пролезет - рядом с вон теми цифрами не стояли.
> да и на входе интерливера бит очень много.
> Получить коллизию внутри сектора в нескольких алгоритмах одновременно с такой длиной, при
> корректности соседних данных - это надо очень постараться.
Силу FEC берут без запаса, чтобы едва держал "ожидаемый" средний уровень проблем, на грани. Так то FEC может исправлять много чего - вопрос сколько оверхеда на хранение избыточности жаба не удушит. А удушит, потому что место на FEC тратится, юзеру в емкости девайса не видно, а денег на хранение - стоит.
> Одна из причин, по которой из маркетинга исчезло понятие BER и появилось NCER, кстати.
Наружу юзеру актуальнее скорее это. Тем не менее - я вот за свою жизнь видел эн юзерей с убитыми файлухами где энтерпрайзные SSD пошли бэдами, при том отгружая наружу вот имнено трешак с левым содержимым, без IO error. И лезут юзеры с убитыми ФС где явно труха с накопителя приехала. Btrfs'ники в этом в некоем плюсе, там ор csum failed их порой успевает предупредить о факапе до того как он состоится. Но парочку пулов и им разносило. А вон те без чексумм - иногда красиво вылезают из дырки в асфальте, спрашивая что это было. Откуда-то ВНЕЗАПНО упал рояль. А чего ему не быть внезапным то без чексум ФС? :)
Ну и вот глядя на такие приколы я и пришел к выводу что лишний слой чексум - очень даже и неплохая идея. На практике довольно много всякой хрени хайлайтит, верифицируя end to end. ИМХО намного более работоспособная тема. И вот там параноики могут уже и криптографический хеш типа SHA256 или blake2 какого втулить, а вот ЭТО уже пробить - ну... попробуйте! Однако это таки еще +32 байта сверху, и само по себе FECом быть не умеет. Ассистентом, детектирующим какая копия верная - еще может быть.

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

371. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 27-Ноя-23, 14:10

> Силу FEC берут без запаса, чтобы едва держал "ожидаемый" средний уровень проблем,
Вы про китайский хлам или что? Так-то нормальные производители FEC берут с хорошим запасом, им не улыбаются ни массовые RMA, ни class action в случае чего.
> энтерпрайзные SSD пошли бэдами, при том отгружая наружу вот имнено трешак с левым содержимым
Какой-то подвальный энтерпрайз или битый контроллер? Битый контроллер или память контроллера развалит всё содержимое, да. Прохождение шлака через корректно работающий ECC на контроллере без I/O error - исключено.
> лишний слой чексум - очень даже и неплохая идея
Всё бы ничего, но вместе с этим слоем в нагрузку идут чугунные скороходы.

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

373. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 21:16

>> Силу FEC берут без запаса, чтобы едва держал "ожидаемый" средний уровень проблем,
> Вы про китайский хлам или что? Так-то нормальные производители FEC берут с
> хорошим запасом, им не улыбаются ни массовые RMA, ни class action
А нормальные производители - это кто? А то если взять допустим самсунь - у них например фирмвари по жизни горбатые. И ничего, живут с этим как-то. Хотя на мой вкус там class action давно пора бы, чтоб не смели такой треш в фирмварях на бошки юзеров отгружать. И это - один из топовых производителей флешатины на планете.
Так что оно вот реально делается чтобы не было массоых факапов в период гарантии, соответствие заявленному "на грани" - и не более того. И чем массовее нечто - тем меньше margin, ибо экономия даже центов отливается в солидный куш. Так что в этом смысле, энтерпрайзное железо обычно менее лажовое чем потребительское, но уверенность что там факапов не бывает - не от мира сего.
>> энтерпрайзные SSD пошли бэдами, при том отгружая наружу вот имнено
>> трешак с левым содержимым
> Какой-то подвальный энтерпрайз или битый контроллер?
Если так выкабениваться - весь самсунг можно этим термином назвать. А они по моему #1 по производству флеша на планете на ваше горе.
> Битый контроллер или память контроллера развалит всё содержимое, да.
Прелесть чексум в том что они все это еще и обнаруживают. В случае избыточности - еще и в моменты пока оно вполне себе корректируемо было - и можно вовремя отреагировать. А если проблему игнорить, она усугубится - и все разлетится к хренам.
> Прохождение шлака через корректно работающий ECC на контроллере без I/O
> error - исключено.
Я своим глазам и недовольным юзерям постящим логи верю больше чем каким-то теоретикам с опеннета, камлающим на непогрешимость проприетарных блобварей. Хотя бы потому что им врать резона нет, они приходят узнать "а как мне это починить". Или в случае btrfs - узнать баг btrfs ли это или что-то иное. А им и грят - мол, чуваки, меняйте ASAP свой накопитель, он у вас сыпется! Это нормальные "рабочие процессы" вокруг файлух видимые мне. Вы с ними спорить удумали? По моему спорить с наблюдаемыми фактами - тупая затея. К ним можно только адаптироваться - и желательно подрихтовать дизайны и дефолты файлух. Дада, и DUP в metadata бтрфсники вернули на SSD не от хорошей жизни. А потому что выживаемость ФС повышает.
>> лишний слой чексум - очень даже и неплохая идея
> Всё бы ничего, но вместе с этим слоем в нагрузку идут чугунные скороходы.
Это не скороходы, это гипердрайв. Да, специфичный, но - за освоение более чем воздается. А вы можете воооон там этажерку из LVM/dm/md и прочь себе слепить, чо. Получите подобие таких фич, но правда, рекаверить будет не сильно проще, а управление - намного геморройнее. Ну вот и выбирайте, как оно вам... хотя можно и технологией страуса, но так я бы никогда и не узнал о вон тех взбрыках. И глядишь верил бы таким сказочникам с опеннета как dурак. А вот тут я могу с чистой совестью отправить таких сказочников с их идеальным железом курить бамбук - наблюдаемые данные были другими и не стыкуются с этим спичем. Значит это хреновая теория и она идет в треш.

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

333. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 26-Ноя-23, 12:08

Ну смотри - пока ты искал битвротики в ECC - твоя ZFS тебе незаметно порола данные, выдавая нули вместо блоков при определённом схождении звёзд. Появление подобного бага было вполне ожидаемо, учитывая монструозность этого поделия - с самого начала его существования.

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

335. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 26-Ноя-23, 12:21

И вот конкретно поэтому лучше выбирать простые как доска стеки - ECC накопителя, спасающий в общем и целом от битовых ошибок при чтении, RAID, спасающий от реальных uncorrectable, и простую как доска файлуху - в моём случае это либо ext4 либо ocfs2 (где кластеры). С этого всего в случае термоядерного 3.14ца можно хотя бы что-то руками достать, в отличие от. Дальше идёт платформа с ECC у памяти - ага, основной вероятный источник повреждения данных. И бэкапы. К которым, я правда, за 15 лет ни разу не обращался из-за нарушения целостности данных, и которые пока пригодились только исправлять последствия кривых лапок у самих юзверей.

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

358. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 02:20

> И вот конкретно поэтому лучше выбирать простые как доска стеки
Глядя на количество юзеров которым энтерпрайзне SSD вынесли ЭТО внезапным роялем, а также сколько кривого железа btrfs отловил из того что на виду - вы имхо это у себя и практикуйте. И там камлайте на супер-девайсы, думая что все ЗБС. Без средств для измерения что и правда - ЗБС.

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

73. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от пох. (?), 23-Ноя-23, 14:16

> Выкинуть бы всё это "творчество", но проблема только в том, что другого
> решения для raid5/raid6 с хешами для проверки целостности данных на дисках
тебе решение для локалхоста или данные хранить? Для второго "другое" - не-open solaris, или хотя бы вот FreeBSD до эры тяпляперов (т.е. 11.1 какая-нибудь)
> в общем-то и нет, а обнуление секторов или просто их порча
> даже при не особо большом объёме данных происходят регулярно...
э... понятно...

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

111. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –2 +/–

Сообщение от fidoman (ok), 23-Ноя-23, 15:55

>> в общем-то и нет, а обнуление секторов или просто их порча
>> даже при не особо большом объёме данных происходят регулярно...
> э... понятно...
В смысле, ты даже не читал статьи на тему того, зачем вообще контрольные суммы в ZFS ввели?
И не встречал дисков, которые побитые сектора вместо того, чтобы записать в pending, тупо их ремапят, заполняя нулями? И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?

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

188. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:21

> И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
> pending, тупо их ремапят, заполняя нулями?
Это как правило диски под линейную циклическую видеозапись, зачем вы их такие берёте?
Плюс стандартный RAID5 такое щщастье замечательно отработает.

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

265. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от нах. (?), 24-Ноя-23, 13:40

>> И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
>> pending, тупо их ремапят, заполняя нулями?
> Это как правило диски под линейную циклическую видеозапись, зачем вы их такие
причем прошлого десятилетия. Я не слышал о подобных проблемах у пресловутых wd purple. Ремап как ремап.
> Плюс стандартный RAID5 такое щщастье замечательно отработает.
нет. как он тебе его отработает если там нули вместо данных и неизвестно, где?
Специальных проверок что если считались нули то считать этот сектор битым пока не предусмотрено (да и где гарантия что нули и не были там на самом деле)
data checksums тут помогут, только вот не лучше ли не использовать настолько неадекватное оборудование?
Я за свои тридцать лет работы в околоит ни разу не видел никакого битрота. И даже настолько неисправные диски что превращают данные в кашу (это не битрот, битрот сказочка о другом белом бычке - якобы-единичном перевороте битика где-то в середине стотридцатого терабайта очень нужных данных [которых у сказочника никогда не было]) мне не попадались. Вероятнее всего в виду не покупания их на помойках.

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

223. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от Аноним (-), 24-Ноя-23, 02:32

> И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
> pending, тупо их ремапят, заполняя нулями?
Это вообще - unspecified. Фирмвара что хочет - то и делает. Нет никаких требований что должно случиться если энный сектор прочитать не удалось. Ну а поскольку корректных данных нет - упс, сохранить данные неизменными, как записано как раз и не получится. Хоть как.
> И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?
Он вообще не в курсе parity это кривой или данные. RAID1 тоже при этом без понятия - какая из копий правильная. При обычном подходе вы видите что 2 копии не совпадают - но это ничего не говорит о том какая из 2 правильная. С чексумами, однако, этот пазл и решаем, и чинится в фоне, позволяя заодно и ремап сделать без проблем.

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

236. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –1 +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:51

>> И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?
RAID 5/6 и не надо быть в курсе - и вменяемые контроллеры делают проверку при регулярных прогонах Patrol Read / Consistency Check. Нет, не при каждом хостовом чтении естественно, но при каждом чтении оно и не нужно - оно нужно чтобы как раз найти сектора, которые вот такие вот гнилые диски забили фигнёй.

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

237. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +1 +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:52

В любом случае подобные диски и данные, которые жалко - это неюзабельный кейс, который не вижу смысла далее рассматривать.

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

359. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 02:35

> RAID 5/6 и не надо быть в курсе
У меня другие идеи на этот счет. С чексуммами соотношения явно лучше, при том достаточно малой ценой. И даже RAID5 в небольших инсталляциях может иметь какой-то смысл, а RAID1 и подавно.
> - и вменяемые контроллеры делают проверку при регулярных прогонах Patrol Read
> / Consistency Check.
Ну да, ну да, специальное железо за дохреналион, с мутной фирмварой делающей хз что, в которой отсутствие багов гарантирует - ахз, наверное Пушкин. А знаете что господа, вы такими требованиями и свойствами - в усмерть уже задолбали много кого. За что и повылетите почти отовсюду, имхо. Вместе с железками за дохраналион. Ибо "кайф то в том и заключается чтобы вовремя их с рельсы убрать!" - сделать дешево и круто. И это - на ваше горе возможно.
И даже не только на уровне 1 тазика. Более глобально, из ненадежных тазиков можно собирать надежные гипер-структуры. Чем вон те энтерпрайзники и занимаются. Ну а вы на этом фоне - пушистые мамонты, над которыми летают звездолеты более разумных существ. А климат уже не в вашу пользу.
> Нет, не при каждом хостовом чтении естественно, но при каждом чтении оно
> и не нужно - оно нужно чтобы как раз найти сектора, которые вот такие вот гнилые
> диски забили фигнёй.
Гнилость диска понятие весьма широкое. Может и 1 бэд в 5 лет вылезти. Вон то его прозрачно парирует, и поедет дальше. И если следующий будет через 5 лет - возможно не такой уж диск и гнилой.

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

366. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 27-Ноя-23, 10:04

Я тут уже пару раз писал, и в третий тебе напишу: за 15 лет ни одного обращения к бэкапам.
Но вы продолжайте получать удовольствие.
Из ненадёжных тазиков никакие надёжные структуры вы не соберёте. Нет - соберёте. До первого залетевшего дятла. Не вы первые, не вы последние. Даже гугл тазики такого типа ставит только на GGC, который потерять не жалко.

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

374. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 21:25

> Я тут уже пару раз писал, и в третий тебе напишу: за
> 15 лет ни одного обращения к бэкапам.
Вы ни разу не ответили мне на 1 простой вопрос - как вы вообще проверяли целостность данных. Как это происходит с фоновыми сканами типа scrub - я понимаю. Как это у вас - не совсем. Откуда у меня подозрения насчет "технологии страуса" и следствий из законов Мерфи.
> Но вы продолжайте получать удовольствие.
> Из ненадёжных тазиков никакие надёжные структуры вы не соберёте. Нет - соберёте.
Гугл собрал. Там отказ 1 сервера - вообще ни на что не влияет. При этом все равно почему он скопытился. Более глобальная структура делает резервирование рассматривая каждый тазик как юнит.
Да вы и сами - собраны из ненадежных клеток. Каждый день у вас умирает куча клеток. А вы тут пописываете на опеннетик и в ус не дуете о проблемах отдельных "юнитов".
> До первого залетевшего дятла. Не вы первые, не вы последние.
> Даже гугл тазики такого типа ставит только на GGC, который потерять не жалко.
Ну вы можете дать гугле и еще нескольким крупным мастеркласс как это делать. Но вообще-то дятел намекает - что климат изменился, и вам вообще совсем амба.

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

375. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 27-Ноя-23, 23:08

> Гугл собрал.
Ничего гугл не собрал. Вы их самодельные тазики, которые сервис, а не no-problem-to-drop кешик видели? Ваши супермикры или что там у вас сейчас китайское модно - рядом не валялись. Там даже платы, ***а, кастомные...

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

377. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (-), 28-Ноя-23, 04:12

>> Гугл собрал.
> Ничего гугл не собрал. Вы их самодельные тазики, которые сервис, а не
> no-problem-to-drop кешик видели? Ваши супермикры или что там у вас сейчас
> китайское модно - рядом не валялись. Там даже платы, ***а, кастомные...
Вы не понимаете (хотя это нормально, когда уровень обсуждаемого превышает способности обсуждающего).
Основная круть гугла (что конкуренты никак не могут содрать, вебманкам слабо, как впрочем и вам) - overlay алгоритмы, позволяющий хранить данные "распределенно" в "мегаструктурах". Вылет плюс-минус пары серваков пофиг, из-за наличия избыточности на ЭТОМ уровне, "в сети". Сетевая мегаструктура просто самовосстановится. Может что-то где-то пару реплик на другие узлы раскидает.
Для юзеров это будет как максимум кратковременная просадка перфоманса. А в остальном оно самопочинится, все продолжит работать, техники где-то в фоне заменят плюс-минус пару серверов. И если алгоритм сформулирован вот так - в эту формулу вообще не входит какая там плата, и по какой причине сдох сервак.
Вы не соберете такое ни из супермикр, ни из чего там - потому что это "глобальный сетевой алгоритм" прежде всего. И гугл разумеется в жизни вам ЭТО не даст в полном и работающем виде. Что они, глупые себе конкурентов взращивать.
Пох, или кто там, периодически пиндит про какие-то патчи для EXT, которые гугол зажал. Гугол вообще гонял ФС без журнала, и их integrity в вон том кейсе - ниипет вообще, чек блоков и ререпликация рюхается сетевым уровнем, а сервер опознается как испорченый и по отгрузке трухи по любой причине и по уходу в даун, это не важно - запрос будет просто повторен на другие узлы и завершится успехом. Но вам такой EXT вообще нафиг не упал, ибо плевал он на целостность данных. Особенно с вашим пониманием как делать те или иные вещи. Это просто не ваш уровень технологий. В отличие от вас я немного понимаю как делать такие штуки. По каким-то своим причинам, столь же за гранью вашего понимания как и сами такие технологии. Даже если вам дать те EXT патчи - куда вы это? У вас же нет такого сетевого оверлей-алгоритма. И врядли будет. Не дают инопланетяне продвинутые космические корабли всяким питекантропам. А с вашим EXT4 и энтегпгайз хагдвагом соотношения примерно вот такие.
А меня продвинутые ФС с чексуммами интересуют потому что вон то поднять локально, таки, очень накладное мероприятие и "вниз" такое сложно масштабировать и соотношения портятся. Одно дело пережить отказ 3 серваков из 1000, другое 3 из 5, допустим. Если мы про FEC - это требует более другой уровень оверхеда для парирования. Да, FEC можно делать в разных масштабах. Очень разных. А "страйпом" может быть и "узел сети". При этом пофиг на его внутренние проблемы и китайский он там и проч - единственное что меняется, гимор с заменой и возможность глобально управлять этим в желаемом формате (последнее и является настоящим поводом разработать свое).

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

383. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 28-Ноя-23, 09:27

Вы просто не понимаете, что это целый комплекс мер.
Распределённые структуры очень медленно ворочаются как на запись, так и менее - на чтение, а при отказах имеют свойство ворочаться ещё медленнее, потому что начинается тот самый процесс восстановления. А при отказе большего, чем ожидалось, числа нод - могут лечь совсем до ручного вмешательства. У гугла сервисных нод очень много, но пренебрегать их надёжностью они при этом не рискуют. А вот на кеш (который пишется исключительно с сервисных нод и далее работает в режиме read-mostly) - ставят хлам, да.
И если вы считаете, что из хлама можно собрать космический корабль - ну вот да, Луна-25 - примерно ваш уровень.

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

388. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –1 +/–

Сообщение от Аноним (-), 28-Ноя-23, 15:50

> Вы просто не понимаете, что это целый комплекс мер.
На мой вкус - сперва извольте ответить на вон тот простой вопрос, как вы вообще на ващих EXT'ах узнавали что данные не побились - а потом будете щеки надувать. Поставить фирмачей на дохреналион, надув щеки, ума много не надо. А вот сделать "недорого и круто" - это и есть state of art.
> Распределённые структуры очень медленно ворочаются как на запись,
Вообще ниоткуда не следует. В энных допущениях может быть ограничено только каналом writer'а по сути.
> так и менее - на чтение,
Тоже ниоткуда не следует. Там можно параллелить запросы и проч - и в предельном случае это может забить любой канал. Характерным примером является допустим торент. Да, это специфично, но общие идеи чем это может быть при правильном подходе - иллюстрирует. Попробуйте перефлудить сидеров исошки убунты вообще. Они круче любого CDN. Вот гугл какие-то такие моменты - понял.
> а при отказах имеют свойство ворочаться ещё медленнее, потому
> что начинается тот самый процесс восстановления.
Это могут быть вполне прозрачные и ненапряжные процессы, а основной деградеж перфоманса - потому что число серверов отгружающих вот именно эти блоки тем кто их хотел временно просело а нагрузка - нет.
> А при отказе большего, чем ожидалось, числа нод - могут лечь совсем
> до ручного вмешательства. У гугла сервисных нод очень много, но пренебрегать
> их надёжностью они при этом не рискуют.
У гугла серверов не много а очень много. И failure rate примерно одинаковый, чего ему резко меняться. И избыточность разумеется его покрывает с запасом. А чтоб мануально - или видимо юзерам? Ну вот не припоминаю каких-то ощутимых сбоев основных сервисов гугли в последнее время.
> А вот на кеш (который пишется исключительно с сервисных нод и далее работает
> в режиме read-mostly) - ставят хлам, да.
Там может и не быть такого деления. От задач зависит. Из хлама можно и всю структуру сделать, единственная трабла - несколько чаще заменять серваки. Ну вон торентовщики - могут любой мусор использовать. Для вас все просто: хеш блока или совпал и тогда все ок, или нет, и тот кто его налил идет в баню (или "маркируется как проблемный сервер" в тех терминах). Какой мусор вам налил блок в этой парадигме вообще не интересно. И "writer"-у в виде initial seeder тоже похрен какой мусор что использует. Круто, да? А таки верификация больших даунлоадов - сильно круче любых HTTP и проч. Те кто поумнее поняли что сравнимые технологии и для иного IO можно практиковать.
> И если вы считаете, что из хлама можно собрать космический корабль -
> ну вот да, Луна-25 - примерно ваш уровень.
Мой уровень на вон тот манер выглядел бы иначе - стайка дронов. Даже если половина развалится и сломается, остальная половина успешно завершит миссию, достроив базу или что там. А не так что 1 супер-дорогой агрегат, а если он сломался то плана вообще нет.
И это... ширпотребный квалкомм с линухом довольно долго рассекал на марсе в виде вертолетика. Я даже со счета сбился, помер он совсем или до сих пор живой. И так то - вот - первый летательный аппарат на другой планете, даром что из ширпотреба.

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

393. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 28-Ноя-23, 21:24

Недорого и круто - это вообще не про гугл.
Следует. Накладные расходы на распараллеливание не учитывать невозможно.
Нет, если вы туда что-то просто пишете, читать не собираясь - параллелится до бесконечности.
Но вот если надо ещё индекс к этому строить - он неизбежно встанет в блокировки.
Всё остальное - беллетристика.

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

398. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (390), 28-Ноя-23, 22:34

> Недорого и круто - это вообще не про гугл.
Это квинтэссенция гугл. Одна из вещей которые конкурентам нечем крыть - они не получают столь же привлекательные условия для себя любимых. Потому что технологически не на том уровне и вынуждены решать проблемы иными средствами, за иные бабки, ну и не могут в результате сервить "условно бесплатно" всю планету с тем же качеством.
И оборудование делать себе тоже не умеют, кроме еще нескольких корп на планете. Так что и удобно на уровне менеджмента систем себе сделать - тоже не могут. Получая дополнительный слой боли и затрат бонусом. Не, никакое супермикро удобно фжйсбуку или гуглу - не сделает. Это только самим себе сделать и можно в нормальном виде. Те кто мог - сделали. Кто не мог - в лузе относительно них по оверхеду на майнтенанс и управление, тем хуже для них.
> Следует. Накладные расходы на распараллеливание не учитывать невозможно.
При правильном подходе к делу - все в пределах разумного.
> Нет, если вы туда что-то просто пишете, читать не собираясь - параллелится
> до бесконечности. Но вот если надо ещё индекс к этому строить - он неизбежно
> встанет в блокировки. Всё остальное - беллетристика.
Это просто очень олдовое и классическое мышление. Уже появились и другие. Вы вот так - даже кравлер веба более-менее реалтаймный не напишете. А иногда индексом вообще может быть - внезапно - сам контент, или запрос. Man "content addressable network" если мозг вдруг не порвется. Те кто поумнее - и сделали себе системы на совсем других принципах. А всякие похи жалуются что им патчик для генератора энергии не дали. Куда они этот генератор без остального крейсера и варпдрайва интерфейсить собирались - кто его знает. Воинственно трясти копьем это ж не мешает.

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

403. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 29-Ноя-23, 09:38

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

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

409. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 01-Дек-23, 21:37

> хеш блока или совпал и тогда все ок, или нет, и тот кто его налил идет в баню
В распределёнках самое интересное начинается именно тогда, когда НЕ совпал.
Вот там приключения Чиполлино в стране крокодилов развёртываются в полный рост.
А если внезапно связность между нодами ушаталась - то начинаются приключения снежка в аду.

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

287. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от пох. (?), 24-Ноя-23, 19:38

> Это вообще - unspecified. Фирмвара что хочет - то и делает. Нет никаких требований что должно
> случиться если энный сектор прочитать не удалось.
казалось бы - очевидно, что - вернуть ошибку чтения, а не произвольные данные с потолка.
Если вы напоролись на диски которые вместо этого возвращают какие-то там нули - назовите конкретную модель.
И да, никакой raid5 от этого не поможет. Там дальше очередные фантазии каких-то местных экспертов.

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

295. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 24-Ноя-23, 22:03

Не, такая серия у сигейта действительно была. Video-only. Этот треш действительно забивал сектора при ремапе (видеопотоку-то фиолетово), в рейды его категорически ставить было нельзя.

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

310. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." –1 +/–

Сообщение от Аноним (309), 25-Ноя-23, 12:45

> Не, такая серия у сигейта действительно была. Video-only.
Названия модели или серии так и нет, зато есть обобщение на все диски под видео.
> Диски под видео - отдельный экземпляр, их здесь где-то ниже упомянули - вот эти да, страшное дело - могут просто смахнуть сектор и сделать вид, что прочиталась фигня. Эти диски лучше никуда больше не ставить.
ATA Streaming feature set появился не позже 2004, со специальными командами для "priority on the time to transfer the data rather than the integrity of the data". Заявление о дисках, которые переносят поведение специальных команд на обычные, звучит совсем неубедительно. Эти команды были придуманы, чтобы не менять поведение обычных, нужна конкретная багованная модель без обобщений.

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

346. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от пох. (?), 26-Ноя-23, 17:07

>> Не, такая серия у сигейта действительно была. Video-only.
> Названия модели или серии так и нет, зато есть обобщение на все
да какая разница? все равно ты в розницу это чудо не купишь. Что-то специфичное с whitelabel (или как у сигейтов выглядит аналог) ставившееся только в dvrы подключенные к камерам наблюдения. Чтоб видимо использовать там шва6одное по а не самим писать драйвер с чудо-фиче-сетом.
Ну будешь такой на помойке расковыривать - прояви осторожность. А в остальных случаях знание малополезное.

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

351. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Tron is Whistling (?), 26-Ноя-23, 22:49

А вот это - да, верно.

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

361. "В OpenZFS выявлена ошибка, которая может привести к поврежде..." +/–

Сообщение от Аноним (319), 27-Ноя-23, 03:07

>> Это вообще - unspecified. Фирмвара что хочет - то и делает.
>> Нет никаких требований что должно случиться если энный сектор
>> прочитать не удалось.
> казалось бы - очевидно, что - вернуть ошибку чтения, а не произвольные
> данные с потолка.
А кто его знает что в голове у тех разработчиков фирмварей. Они решили делать вот так. Это поведение найдено в диком виде для целой кучи девайсов всех мастей и направлений. Чаще всего так flash based прикалывается, для HDD это скорее исключение.
Видимо идея в том что сектор не так уж сильно испорчен и несколько битых битов не такой уж и ужас, даже если FEC и лоханулся, так что может лох и не заметит. Как видим, с господами любящими EXT4 это до некоторой степени катит, чексум же нету! Они и будут уверены что все ЗБС. Если б при частых ошибках такого вида не разлеталось внезапным роялем на бошку, может никто и не заметил бы. Но вон те - вылезающие из дырки по форме тушки и удивленно спрашивающие что случилось и где их данные таки стали вызывать определенные вопросы, эффект и был опознан и классифицирован.
> Если вы напоролись на диски которые вместо этого возвращают какие-то там нули
> - назовите конкретную модель.
Это больше характерно для флешастых девайсов, особенно заезженных, а быстро заездить энтерпрайзный SSD можно воткнув его в bcache например. Популярный способ. Девайсы - разные бывают. Самсуни всякие например. У них вообще фирмвар - стремный по жизни. А еще раньше они от trim себе харакири пытались делать. Достаточно успешно, чтобы загреметь в блеклисты линукс кернела, которые, так то - забавный клад на тему quirk'ов самой разной хрени.
> И да, никакой raid5 от этого не поможет. Там дальше очередные фантазии
> каких-то местных экспертов.
В чистом виде? Умрет в корчах. С чексумами - таки определенные шансы имеет. Ибо за счет чексум известно где левак.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

53. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от fidoman (ok), 23-Ноя-23, 13:45
Выкинуть бы всё это "творчество", но проблема только в том, что другого решения для raid5/raid6 с хешами для проверки целостности данных на дисках в общем-то и нет, а обнуление секторов или просто их порча даже при не особо большом объёме данных происходят регулярно...
Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:03
	Чего, простите? RAID5/6 собственно и позволяет проверить целостность...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	112. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от fidoman (ok), 23-Ноя-23, 15:58
	> Чего, простите? > RAID5/6 собственно и позволяет проверить целостность... RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	139. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от аНОНИМ (?), 23-Ноя-23, 17:31
	> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой. А вот RAID6 теоретически позволяет (если битые данные на одном диске из всех), но опять же нихрена такого mdraid не делает. Я проверял.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	226. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 03:12
	>> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой. > А вот RAID6 теоретически позволяет (если битые данные на одном диске из > всех), но опять же нихрена такого mdraid не делает. Я проверял. А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает. Выглядит как потрошеный окунь в живой воде у стругацких, но при всем этом - еще и работает. Крутануть теорвер в свою пользу - по своему забавно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	228. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от аНОНИМ (?), 24-Ноя-23, 09:09
	> А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает. На бтрфс с миррорами -- работает. С раид5-6 когда я проверял (довольно давно) -- НЕ работало. Отдавало примерно половину файлов или меньше, остальные io error. А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало. Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom of=/весь/девайс/из/рейда и монтировал ФС взад. ZFS усралось спамить в dmesg, но всё железобетонно отдало. А после скруба стало как новое. btrfs с raid5/6 обломался. Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	323. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 26-Ноя-23, 01:16
	>> А на btrfs такое даже работает, я для RAID1 и DUP проверял > На бтрфс с миррорами -- работает. А я умею читать документацию, и если нечто озвучено как экспериментальная фича - ну я и делаю определенные выводы. Впрочем - там можно и более продвинуто. Скажем если метаданные RAID1 (или даже RAID1C3 для фанатов RAID6) а данные RAID5/6 - это уже более интересное комбо. Потому что write hole перестает импактить метаданные, а остальное - все же менее проблемный топик. Если метаданные живые, все намного оптимистичнее в плане перспектив. На самом деле write hole там можно аннулировать scrub после краха, но это неудобное требование. Более полное решение требует изменение структур ФС для логинга write intent и все такое. > С раид5-6 когда я проверял (довольно > давно) -- НЕ работало. > Отдавало примерно половину файлов или меньше, остальные io error. RAID5 таки довольно заметно пофиксили - хоть и ценой потери перфоманса в ряде операций, ибо полный RMW страйпа делается чаще. В паре с RAID1 для метаданных, можно уже даже попробовать потрепыхаться. Но официально все равно experimental, и если что - ну, девы честно сказали как оно. Мне честное описание свойств - больше нравится чем красивые сказки. Меньше неприятных сюрпризов. Больше места для информированных осознанных решений. > А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало. Да вот судя по новости, с дополнениями, где вообще рефлинки, кажется, амнистировали - но теперь вообще "хрен бы его знает что это и где" - потому что походу накрывает и старые корутилсы, и более лохматые версии без рефлинков, там целая детективная история, где встречаются джамшуты месившие хз что, паленые материалы, и пара обрушившихся зданий, после чего и стали изучать что за фигня такая с этим железобетоном. > Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom > of=/весь/девайс/из/рейда и монтировал ФС взад. > ZFS усралось спамить в dmesg, но всё железобетонно отдало. > А после скруба стало как новое. btrfs с raid5/6 обломался. Ну вон то какой-то не особо реалистичный случай отказа. Чему в реальном мире ЭТО соответствует? > Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде. Могло на слет супера обидиться еще. Но в таком случае вы всяко ребилд девайса по всей площади делать будете, плюс-минус передобавка девайса чтобы супер нарезать Более того - я не совсем понимаю как идентифицировать девайс без супера как свой. По буковкам? Это достаточно чревато, ща линукскернель оборудованеи асинхронно инициализирует, буковки - ну вот не обязаны мировой константой быть. У вас - ну вы все 3 копии супера вынесли. В реальных сценариях, от них или что-то останется, или это полный отказ и замена девайса с полным ребилдом соответственно. Разработчики btrfs все же на реалистичные сценарии ориентировались. А как там какая тушка с оторваной головой бегает - ну, не очень интересно, имхо. Интереснее чтобы с типовыми факапами железа справлялось. И в этом смысле - накопителей подсирающих трухой в секторах сейчас заметно прибавилось например. Я не спорю что вон то забавные тест, но он не соответствует ни одному из real workd сценариев отказа сторажей которые я видел.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	168. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (165), 23-Ноя-23, 19:44
	Я смотрю ты шаришь. Не объяснишь по простому, что такое write gap у RAID5/6?
	Ответить \| Правка \| К родителю #62 \| Наверх \| Cообщить модератору


	182. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 22:58
	Не объясню - это ошибочный термин.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	183. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:00
	И применять его в контексте рейда не следует, термин write gap действительно существует - но он относится к аппаратуре записи магнитных накопителей, а вовсе не к рейду, и не имеет прямого отношения ни к надёжности, ни к производительности, хотя влияет на оба параметра.
	Ответить \| Правка \| К родителю #168 \| Наверх \| Cообщить модератору


	204. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (204), 24-Ноя-23, 01:04
	Тогда мне поясни за wright hole.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:04
	Если у вас порча секторов происходит регулярно - есть смысл посмотреть в сторону стабильности платформы, скорее всего данные теряются до записи на диск. Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор не может.
	Ответить \| Правка \| К родителю #53 \| Наверх \| Cообщить модератору


	110. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–3 +/–
	Сообщение от fidoman (ok), 23-Ноя-23, 15:49
	> Если у вас порча секторов происходит регулярно - есть смысл посмотреть в > сторону стабильности платформы, скорее всего данные теряются до записи на диск. > Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор > не может. google:bitrot
	Ответить \| Правка \| Наверх \| Cообщить модератору


	184. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:03
	Плджад. Там ECC. Причём на современных накопителях - не обязательно одноуровневый даже.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	191. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:37
	Поэтому никакой битврот вы получить не можете. Если вдруг ошибка пройдёт ECC, вероятность чего запредельно мала - вы вместо данных в секторе (512 байт или целых 4К ныне) получите кашу, потому что наборов данных, подходящих под один и тот же "хеш" ECC (там конечно не хеш, там многомерные поля, но не будем об этом) - не много.
	Ответить \| Правка \| К родителю #110 \| Наверх \| Cообщить модератору


	114. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от fidoman (ok), 23-Ноя-23, 15:59
	> Если у вас порча секторов происходит регулярно - есть смысл посмотреть в > сторону стабильности платформы, скорее всего данные теряются до записи на диск. > Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор > не может. ECC пропускает ошибки с вероятностью, которая на больших системах (или при длительной эксплуатации средних) заметна практически.
	Ответить \| Правка \| К родителю #63 \| Наверх \| Cообщить модератору


	185. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:05
	Чего? Чтобы ECC современного накопителя пропустил ошибку - надо очень постараться. Современные HDD и SSD вообще только благодаря ECC можно сказать и работают, если чисто гипотетически убрать ECC - их использовать будет вообще толком невозможно. Ещё раз повторюсь: если у вас это возникает регулярно - смотрите в район платформы, а не накопителя.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	221. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–3 +/–
	Сообщение от Аноним (-), 24-Ноя-23, 02:26
	> Чего? Чтобы ECC современного накопителя пропустил ошибку - надо очень постараться. Агаблин, а у меня есть текучая флеха где EXT4 за месяц - в труху. Наверное это мой глюк? Не, IO Error эта пакость наверх не репортит. Просто грузит труху периодически. Btrfs в схеме DUP - даже на таком живет. Заодно позволяя измерить частоту факапов. На этом экземпляре - если записать, через недельку scrub налетит на 10-20 секторов которые разъехались по чексумам. И это тебя жестко оспаривает. Стараться там вообще не надо, надо записать эн гигз, а потом через недельку scrub запустить и получить свои чексум ерроры. Просто как топор, воспроизводимо. > Современные HDD и SSD вообще только благодаря ECC можно сказать и работают, А если еще и изучить математику за ECC - можно узнать что эти алгоритмы имеют заметно отличную от ноля вероятность посчитать блок за исправный, хотя там труха. При достаточном числе read errors и большом числе попыток в какой-то момент вы таки можете и выиграть в эту лотерею. А экстремальный случай мне вот за счет btrfs'а "отфильтровался" под внимание. > если чисто гипотетически убрать ECC - их использовать будет вообще толком > невозможно. А чисто практически - накопители, особенно флешовые, имеют манеру выгружать какой-то крап, далеко не всегда утруждая себя репортом IO Error при этом. > Ещё раз повторюсь: если у вас это возникает регулярно - смотрите в > район платформы, а не накопителя. Повылезло тут экспертов мля со своими EXT4 и XFS, измерявшим разрушения хз как, видимо теориями. А таки - чексумы в ФС - отличная штука. И ZFSники в этом были правы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	141. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от аНОНИМ (?), 23-Ноя-23, 17:36
	> Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор не может. Странно как-то, "у накопителей свои ECC", но вот параметр BER для накопителей тем не менее приводят: https://documents.westerndigital.com/content/dam/doc-library... (1 ошибка на 10^15 бит). И если его пересчитать в терабайты прочитанного, это будет всего-то сотня терабайт. Откуда сразу следует вывод, что хранить данные на raidz1/raidz2, где каждый блок на каждом диске защищён отдельной чексуммой -- есть смысл. А кому собственные данные не важны -- ну те ext4 пользуются, вон как диванные эксперты вокруг.
	Ответить \| Правка \| К родителю #63 \| Наверх \| Cообщить модератору


	186. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:19
	Звон-то вы слышали... Хоть бы потрудились сами почитать, что запостили. Начнём с BER. BER - оно и есть приблизительная оценка частоты срабатывания ECC в обычных условиях работы, без повреждений накопителя. Как часто будет возникать ошибка ECC при чтении в штатных условиях. Я выше написал: если бы не ECC - да, накопителями бы вообще пользоваться невозможно было. Теперь к вашим баранам. В том, что вами приведено - это не BER. Это NCER. Non-correctable (там non-recoverable) error ratio. Это количество бит, среднее, прочитанных, после которого вы получите неисправимый сбойный сектор. Не 1 на 10^15, а <1 на 10^15. Разницу улавливаете? Менее одной неисправимой битовой ошибки на 125 прочитанных терабайт. Эту ошибку поймает та самая ECC, и выдаст как нечитаемый сектор. К сожалению да, для современных накопителей в десяток и более ТБ - этот параметр неизмеримо мал. Их только в рейд и ставить. ECC false positive ratio же на несколько порядков меньше, данные ECC в современных хардах запросто могут весить ~10% и больше от сектора, плюс как правило многоуровневая ECC - одна в коде записи и другая в записываемых данных. А у более надёжных драйвов ещё и цикл WRV бывает добавлен, но это уже детали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	187. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:19
	Почему ныне не приводят BER? Цифирь слишком неприглядная. При штатном чтении многобитовая ошибка - норма жизни. Особенно на черепичках.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	190. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:32
	Тут правда я одну вещь не упомянул. Наличие NCER не значит, что сектор не прочитается хостом вообще совсем никак. Сначала диск попробует перечитать, первые ошибки при отсутствии серьёзного повреждения магнитного слоя обычно статистически не значимы. Далее оно со 2-3-5-10 попытки скорее всего прочитается. И когда прочитается - сектор будет стёрт и испробован на запись. Если после испробования сектор не пройдёт по числу битовых ошибок в той самой ECC - будет отправлен в другое место диска, получите ремап. На черепичках может быть так лёгкой рукой смахнута в другое место целая группа секторов. Всё это незаметно для хоста, естественно. То есть само по себе NCER ещё не фатал. Реальную ошибку вы получите только если операция чтения свалится в совсем никак, даже после пары перепозиционирований голов. Диски под рейд настроены делать меньше попыток, диски под бытовуху - больше. Но тем не менее, средние 125 Тб на 22 Тб хард - это запредельно мало. О времена, о нравы. --- Диски под видео - отдельный экземпляр, их здесь где-то ниже упомянули - вот эти да, страшное дело - могут просто смахнуть сектор и сделать вид, что прочиталась фигня. Эти диски лучше никуда больше не ставить.
	Ответить \| Правка \| К родителю #186 \| Наверх \| Cообщить модератору


	230. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от аНОНИМ (?), 24-Ноя-23, 09:15
	> Наличие NCER не значит Вообще-то как раз и значит, иначе бы его маркетолухи не назвали бы "NON-correctable"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	232. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:41
	Для начала давай ещё раз поясню, что такое NCER в этом контексте. NCER - это значит, что сектор с первого раза корректно прочитать не удалось. Не просто ECC отработала (это BER, точнее не совсем BER, но опустим), а ECC сказала, что всё, задница. Но это не значит, что его не удастся прочитать со 2 захода например.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	254. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от аНОНИМ (?), 24-Ноя-23, 12:23
	> Но это не значит, что его не удастся прочитать со 2 захода например Это ниоткуда не следует. И в даташите не написано. Значит -- не факт и я имею право предполагать худшее. Речь-то о моих данных. Примеры обратного были тут где-то рядом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	294. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 24-Ноя-23, 22:01
	Можешь предполагать чего угодно. Если данные действительно ценные - надо совсем не ZFS обвешиваться. И порядок денег там будет совершенно другой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	222. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 02:28
	> BER - оно и есть приблизительная оценка частоты срабатывания ECC в обычных > условиях работы, без повреждений накопителя. Как часто будет возникать ошибка ECC > при чтении в штатных условиях. Я выше написал: если бы не > ECC - да, накопителями бы вообще пользоваться невозможно было. Чувак, у меня есть тупо сыпучая флеха юзаемая как стресстест, где "BER" весьма измеримый, без специальных усилий. И весь твой спич на этом фоне можно назвать бесполезным теоретическим булшитом не стоящим байтов истраченых на него.
	Ответить \| Правка \| К родителю #186 \| Наверх \| Cообщить модератору


	233. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:43
	То, что у тебя есть сыпучее китайское говно - это не значит, что его надо в серьёзном проде использовать. Ну, ты - можешь. И да, то, что ты видишь - далеко не BER. Это NC + ECC false positive. В китайских поделках встречается очень часто, поэтому что на ECC тоже экономят.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	327. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 26-Ноя-23, 02:02
	> То, что у тебя есть сыпучее китайское говно - это не значит, > что его надо в серьёзном проде использовать. Да вот знаете, чексуммы очень помогают понять что реально подсунули и как это реально работает. Вместо выслушивания голимых теорий высосаных из пальца. Не нравится флеха? А я и дофига кейсов с энтерпрайзными SSD видел на эту тему. Особенно эффективно получается если его как bcache оформить. И тут то и оказалось что вместо того чтобы сразу и круто помереть - оно при приближении к окончанию ресурса может начать гадить битыми блоками вместо этого. Без всяких IO error. А файлухи на это все реагируют... довольно интересно, скажем так. При том у фанов XFS/EXT4, это вообше как-то так: на них совершенно ВНЕЗАПНО сверху падает рояль и зашибает их до дырки в асфальте. А потом оказывается что осыпающийся девайс гадил, так то, давно - но без чексум это не видно, а развалилось когда уже живого места в ФС нет. XFSники о чем-то даже догадываются и - вон - пыжатся scrub прикрутить. Получается не очень, но почему-то все это идет вразрез с вашими теориями. Btrfs'ники - вот - за счет чексум - такие плюхи ловили на подлете. В отличие от вон тех счастливчиков. > Ну, ты - можешь. И да, то, что ты видишь - далеко не BER. Естественно. Это уже то что за FEC пролезло. > Это NC + ECC false positive. В китайских поделках встречается > очень часто, поэтому что на ECC тоже экономят. Да оно и на энтерпрайзных SSD случается, любители bcache не дадут соврать. Один из аргументов за нормальную интеграцию иерархического кеширования в ФС, там в таких случаях виднее реальное состояние кусков VS запрошенная схема избыточности.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	229. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от аНОНИМ (?), 24-Ноя-23, 09:14
	> Не 1 на 10^15, а <1 на 10^15. Разницу улавливаете? Улавливаю. Жопоруки даже 1e-16 ниасилили. > и выдаст как нечитаемый сектор. Это утверждение нуждается в доказательства. > ECC false positive ratio же на несколько порядков меньше И это -- тоже. Ну вот прям для конкретного жопоруками сделанного накопителя.
	Ответить \| Правка \| К родителю #186 \| Наверх \| Cообщить модератору