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

"В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"	+/–
Сообщение от opennews (??), 23-Ноя-23, 11:30
Доступен промежуточный выпуск проекта OpenZFS 2.2.1, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Выпуск примечателен добавлением поддержки ядра Linux 6.6 и  попыткой устранения проблемы, приводящей к повреждению данных (обнулению части блоков) в файлах после их копирования... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60167
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+20 +/–
Сообщение от Аноним (1), 23-Ноя-23, 11:30
Надежная ФС! Прям как оригинальная ZFS, только пишется не всякими мутными ораклами, а сообществом!
Ответить | Правка | Наверх | Cообщить модератору

	7. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (7), 23-Ноя-23, 11:42
	А вы чего хотели? Всё, что человечество изобретало последние 50 лет, впихнули в единую файловую систему, а теперь удивляются "Ой, ошибка, не может быть!"
	Ответить | Правка | Наверх | Cообщить модератору

	149. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 18:11
	> А вы чего хотели? Всё, что человечество изобретало последние 50 лет, > впихнули в единую файловую систему, а теперь удивляются "Ой, ошибка, не может быть!" В энергосистему из которой вы электричество "качаете" - впихнули все что человечество лет 150 изобретало, но это худо-бедно работает же. p.s. но на фоне вот этого - и траблов рядом где у народа шифрование отваливается и что там еще, отдельные приветы bcachefs. Бывает так что experimental фича в rc1 - качественнее иного release у некоторых. В этом месте манагеры ряда фирм просто обязаны разбить лицо фэйспалмами.
	Ответить | Правка | Наверх | Cообщить модератору

	313. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (313), 25-Ноя-23, 14:19
	в энергетике хорошо работает естественный отбор: если делать плохо, то кого-то либо убьет, либо пожжет имущество. а в ИТ можно "и так сойдет!"
	Ответить | Правка | Наверх | Cообщить модератору

	319. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 25-Ноя-23, 23:29
	Припоминая как дефолтсити вырубился в 2005 - иногда, таки, естественный отбор выглядит гораздо забавнее. И как видите, случается же иногда, несмотря на все старания. Так что в этом смысле они обычные люди. С обычными технологиями, а иногда - и факапами. IT в этом смысле ничем не лучше и не хуже. А глюкавый ECU вас может угробить и побстрее чем высокое напряжение.
	Ответить | Правка | Наверх | Cообщить модератору

	364. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 27-Ноя-23, 10:00
	Гм. Да. Записываем - про энергосистемы вы знаете примерно "ничего" - но аналогия на самом деле неплохая )))
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	9. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+19 +/–
	Сообщение от Аноним (9), 23-Ноя-23, 11:46
	Как всегда больше всех ноют те, у кого ZFS вообще нет)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	21. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (21), 23-Ноя-23, 12:06
	Точно, надо попользоваться, похерить файлы, а уж потом ныть.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
	Сообщение от Всем Анонимам Аноним (?), 23-Ноя-23, 13:53
	О чем как раз и сообщение, на которое вы ответили. Пишут только те, у кого её никогда не было, уж тем более без опыта массового использования для файлов и баз данных. Чисто диванная аналитика. Так держать, opennet.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от None (??), 23-Ноя-23, 15:23
	У меня был опыт использования ZFS для файлов и баз данных. Раз в несколько дней восстанавливать трехтерабайтную постгресную базу - сомнительное удовольствие. Смена ФС решила проблему, больше никогда на ZFS не вернусь и даже смотреть в ее сторону не буду.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 15:48
	> Смена ФС решила проблему Настоящее "инженерное" решение... А что ж тогда оно у других работает и со значительно большей постгрей чем 3 тб?
	Ответить | Правка | Наверх | Cообщить модератору

	158. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от pin (??), 23-Ноя-23, 18:52
	>  Раз в несколько дней восстанавливать трехтерабайтную ой-ли?
	Ответить | Правка | Наверх | Cообщить модератору

	214. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 01:42
	> ой-ли? Я боюсь, вы промахнулись кнопкой - "ответить", т.к. я такой херней не страдаю
	Ответить | Правка | Наверх | Cообщить модератору

	244. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от YetAnotherOnanym (ok), 24-Ноя-23, 11:00
	> и даже смотреть в ее сторону не буду Та же фигня, бро, только с глустером.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	347. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 17:12
	>> и даже смотреть в ее сторону не буду > Та же фигня, бро, только с глустером. не, ну он хотя бы - прикольный.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 27-Ноя-23, 10:02
	Эм. Postgres поверх glusterfs?! Оно и поверх ZFS-то выглядит... интересно, но гластер кмк некторым образом "за гранью".
	Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

	117. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от tim2k (ok), 23-Ноя-23, 16:07
	$uname -a [skipped] 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012 Более 10 лет работы, сейчас аптайм 400+ дней. Машинка изолирована, хранилка для виртуальных машин бодрая.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	150. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 18:12
	> [skipped] 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012 Так оно у тебя в рефлинки и не умело никогда. Нет фичи - нет проблем!
	Ответить | Правка | Наверх | Cообщить модератору

	153. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (153), 23-Ноя-23, 18:32
	Так о том и речь. Если фича не нужна, не беги обновляться.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 18:51
	> Так о том и речь. Если фича не нужна, не беги обновляться. Правильно, зачем кому-то надо 100% легкий, эффективный моментальный "дедуп" без дикого жора проца и рамы. Еще не хватало время и деньги экономить.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (174), 23-Ноя-23, 21:21
	Я так понимаю у тебя проц вчерашнего выпуска, память, материнка навороченная. Чего время и деньги экономить, работая на старых тормозных железках. Надо раз в месяц обновлять, или в пол-месяца. Как что-то фичастое вышло, так и бежать в магазин. Может ему и правда дедуп не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 22:00
	> Я так понимаю у тебя проц вчерашнего выпуска, память, материнка навороченная. Чего > время и деньги экономить, работая на старых тормозных железках. Надо раз > в месяц обновлять, или в пол-месяца. Как что-то фичастое вышло, так > и бежать в магазин. > Может ему и правда дедуп не нужен. Потом довольно часто почему-то оказывается что такие технологии и сотрудники фирмачам тоже не очень нужны - ставят их на бабки на ровном месте.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (180), 23-Ноя-23, 22:48
	> Правильно, зачем кому-то надо 100% легкий, эффективный моментальный "дедуп" без дикого > жора проца и рамы. Еще не хватало время и деньги экономить. Только вот эта пафосная демагогия никак не влияет на наличие zfs snapshot zfs clone
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	202. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (202), 24-Ноя-23, 00:57
	> Только вот эта пафосная демагогия никак не влияет на наличие > zfs snapshot > zfs clone Ну то-есть вы хотите сказать, что кодеры делавшие фичу - позеры и страдальцы фигней? А если вы хотели сказать что-то иное, тогда не понятно почему релиз с такими багами - нормуль. Там вообще тестируют фичи которые вываливают?
	Ответить | Правка | Наверх | Cообщить модератору

	207. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (180), 24-Ноя-23, 01:11
	> Так оно у тебя в рефлинки и не умело никогда. Нет фичи - нет проблем! ... > Правильно, зачем кому-то надо 100% легкий, эффективный моментальный "дедуп" без дикого жора проца и рамы. ... > Ну то-есть вы хотите сказать, что кодеры делавшие фичу - позеры и > страдальцы фигней? > А если вы хотели сказать что-то иное, тогда не понятно почему релиз > с такими багами - нормуль. Там вообще тестируют фичи которые вываливают? Ну то-есть мы опять наблюдаем фирменное 294-ое сруливание с темы ...
	Ответить | Правка | Наверх | Cообщить модератору

	215. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 01:48
	>> А если вы хотели сказать что-то иное, тогда не понятно почему релиз >> с такими багами - нормуль. Там вообще тестируют фичи которые вываливают? > Ну то-есть мы опять наблюдаем фирменное 294-ое сруливание с темы ... Если хотелось мое мнение по теме, посмотрев на баг трек с какими-то несчастными 1.1К открытых багов, и что в них вообще водится, типа "о, шифрование разлетелось, пул в ауте" я таки позволю себе ценное мнение что у проекта, кажись, software quality problems. А в работе с новыми ядрами - там просто капец, жесть и ад. Правильно тут пишут что новее 6.1 с этим лучше не трогать, там счастливчиков с багами - есть. При том я не вижу такой уровень траблов у btrfs несмотря на более плотное общение с ним. Да что там, даже штука от кента - на начальной фазе (!!!) и то менее баговано выглядит. Ну вот такое вот сравнение. Злое зато честное. Что вижу - то и говорю. Сугубо по потоку комитов и багтреку. Я все думал чего пох быкует на этих. Подозревал что мерзкая натура, полить других охота. Но не, походу - господа таки приложили усилия чтобы реально его доожать в эту точку зрения, видимо такие приколы все же имеют свойство отливаться в проблемы эксплуатантов. Ну а за такие вещи репутация все же портится. Давненько я такой жести по FS vs bugtracker не видал...
	Ответить | Правка | Наверх | Cообщить модератору

	135. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от анон (?), 23-Ноя-23, 17:14
	>похерить файлы вот не надо меня пугать, мне после отвалов btrfs еще на zfs такого не хватало.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	243. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от EULA (?), 24-Ноя-23, 10:57
	Просто в BTRFS отвалы тоже из ZFS позаимствованы
	Ответить | Правка | Наверх | Cообщить модератору

	32. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (32), 23-Ноя-23, 12:34
	Именно поэтому у меня её нет и никогда не будет.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	87. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от BorichL (ok), 23-Ноя-23, 14:27
	Да ты и дальше на FAT сиди.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (129), 23-Ноя-23, 17:02
	Где-то fat норм использовать, только тебе в твоём коворкинге про это не расскажут. А так ext4, xfs кошер.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 18:38
	> Где-то fat норм использовать, только тебе в твоём коворкинге про это не расскажут. > А так ext4, xfs кошер. Учитывая что первый вообще на integrity данных с прибором клал? У него чексум нет! Про то чтобы еще и репайрить в фоне побитое с другой копии - речь в этом чуде вообще не идет. А, да, так можно было. А второй - только-только пытаются научить фоновый scrub на манер btrfs/zfs. Правда, судя по недавним мсг в рассылке - это пока больше похоже на "пытался своершить посадку самолет номер 13...", видимо, майнтайер который резко сдриснул оттуда о перспективах догадывался, и решил что тонуть с кораблем - все же не его. Вон то оно само по себе тоже не умеет.
	Ответить | Правка | Наверх | Cообщить модератору

	385. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 28-Ноя-23, 11:22
	Ну, если у тебя data integrity парой уровней выше или наоборот, ниже - то почему бы и не "да"?
	Ответить | Правка | Наверх | Cообщить модератору

	394. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 28-Ноя-23, 21:37
	> Ну, если у тебя data integrity парой уровней выше или наоборот, ниже > - то почему бы и не "да"? 1) Это такое довольно большое "если". 2) Которое к тому же имеет свойство стоить нехило бабок. 3) Не очень понятно откуда бы к этому всему доверия вдруг больше чем к хотя-бы вот этим блохастым. У этих по крайней мере багтрек и комиты на виду, можно объективно их умения и технологии оценить. А у тех, тифозных, даже и такого нет - весь мусор заметен под ковер, предлагается верить джентльменам на слово.
	Ответить | Правка | Наверх | Cообщить модератору

	395. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 28-Ноя-23, 21:49
	>> Ну, если у тебя data integrity парой уровней выше или наоборот, ниже >> - то почему бы и не "да"? > 1) Это такое довольно большое "если". > 2) Которое к тому же имеет свойство стоить нехило бабок. > 3) Не очень понятно откуда бы к этому всему доверия вдруг больше > чем к хотя-бы вот этим блохастым. У этих по крайней мере > багтрек и комиты на виду, можно объективно их умения и технологии > оценить. А у тех, тифозных, даже и такого нет - весь > мусор заметен под ковер, предлагается верить джентльменам на слово. Сюрприииз! Как-то так оно в реальном мире и работает. Enterprise'у дешевле заплатить за нормальную СХД и напрягать вендорский саппорт - который, ёлки, действительно работает - а пионЭры рассказывают, как круто чексуммы ФС решают все и всяческие проблемы... а потом рассказывают в другом месте. Да.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от BorichL (ok), 23-Ноя-23, 19:50
	> Где-то fat норм использовать, только тебе в твоём коворкинге про это не > расскажут. А так ext4, xfs кошер. А чего ты HPFS386 и JFS забыл, или тогда ещё под стол пешком ходил?
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	59. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от ИмяХ (ok), 23-Ноя-23, 13:54
	Это не нытьё, а злорадство "как хорошо, что на моей любимой ext4 ничего подобного нету"
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	71. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+7 +/–
	Сообщение от Аноним (9), 23-Ноя-23, 14:15
	Больше выглядит как "я не разобрался, поэтому у меня ничего нету". Половина виндузятники, вторая половина вообще с телефонов. О проблемах с хранилищами не слышали даже из далека
	Ответить | Правка | Наверх | Cообщить модератору

	136. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (136), 23-Ноя-23, 17:14
	>Половина виндузятники, вторая половина вообще с телефонов. О проблемах с хранилищами не слышали даже из далека Сам-то понял, каким дном свою ZFS выставил, защитничек?
	Ответить | Правка | Наверх | Cообщить модератору

	125. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (125), 23-Ноя-23, 16:42
	Ну да, как же они на ехт4 то без чексумм узнают что у них там что-то повредилось
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	156. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 18:40
	> Это не нытьё, а злорадство "как хорошо, что на моей любимой ext4 ничего подобного нету" На твоей любимой EXT4 ты узнаешь что данные "в труху" исключительно "по факту".
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	11. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Пряник (?), 23-Ноя-23, 11:47
	git blame?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	16. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (16), 23-Ноя-23, 11:54
	> Надежная ФС! Прям как оригинальная ZFS, только пишется не всякими мутными ораклами, а сообществом! факела бсдлюбов особенно хороши :) ext4 используй
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	18. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+4 +/–
	Сообщение от Аноним (9), 23-Ноя-23, 11:57
	Но вы же оба виндузятники, там нет ext4
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–2 +/–
	Сообщение от пох. (?), 23-Ноя-23, 12:35
	там зато есть единственная существующая утилита для восстановления файлов рухнувшего zpool. Правда, она не работает с dRAID и с 2.2 наверное тоже, но у л@п4@тых и такой ведь нет. P.S. драйвер ext4, что характерно - есть, более того - некоторые граждане успешно использовали его для вытаскивания данных с ext4, которая, ВНЕЗАПНО, в линуксе не умеет читать саму себя если записана не на той архитектуре. А в вендепоганой - умеет.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (153), 23-Ноя-23, 13:52
	> которая, ВНЕЗАПНО, в линуксе не умеет читать саму себя Нужны грязные подробности, если это не про поддержку атрибутов в разных версиях ext4.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 14:11
	>> которая, ВНЕЗАПНО, в линуксе не умеет читать саму себя > Нужны грязные подробности, если это не про поддержку атрибутов в разных версиях > ext4. если не умеешь в гугль - воспользуйся хотя бы поиском по сайту.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 24-Ноя-23, 13:14
	Это оно? https://lkml.org/lkml/2018/12/27/155 "d_off field in struct dirent and 32-on-64 emulation" Даже если не оно, то тоже интересно. И на XFS не проявляется.
	Ответить | Правка | Наверх | Cообщить модератору

	337. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от пох. (?), 26-Ноя-23, 16:49
	> Это оно? > https://lkml.org/lkml/2018/12/27/155 "d_off field in struct dirent and 32-on-64 emulation" > Даже если не оно, то тоже интересно. И на XFS не проявляется. не оно, но я не удивлюсь если тут и виндовый драйвер не поможет. Спасибо, в копилочку. P.S. оно - там page size что-ли прибит гвоздями. Ну а у мипса он 1k, кажись, вместо четырех. Оптимизаторы... лечится монтированием через fuse (а ты думал, зачем в дерьмиане ext*fuse?) или вот - ввенде, парагоновский драйвер он "неоптимальный" и читает все.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 14:02
	> единственная существующая утилита для восстановления файлов рухнувшего zpool это какая? Там - это где?
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	65. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–3 +/–
	Сообщение от пох. (?), 23-Ноя-23, 14:10
	где-где - ввенде! гуглем пользоваться уж как-нибудь сам учись.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 18:54
	> там зато есть единственная существующая утилита для восстановления файлов рухнувшего zpool. > Правда, она не работает с dRAID и с 2.2 наверное тоже, но у л@п4@тых и такой ведь нет. Да ващет в этом нашем btrfs - такая штука встроена прям в штатный тулкит ФС. И работает ессно в линухе. По этой причине тулсов для этсамого для виндов vs btrfs не очень то и есть, комерсам всю малину разработчики ФС испортили.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	179. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (179), 23-Ноя-23, 22:07
	И об этом ты ещё до войны разговаривал с господином окружным начальником.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (262), 24-Ноя-23, 13:10
	Это какие? Которые ZFS сначала закрыли, чтобы барыжить, а потом поняли, что поздняк метаться и стали вдохновляться (переписывать исходники) ZFS в BtrFS. Вот это поворот! Оракле некомерсом назвали.
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	283. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 18:30
	> Это какие? Которые ZFS сначала закрыли, чтобы барыжить, а потом поняли, что > поздняк метаться и стали вдохновляться (переписывать исходники) ZFS в BtrFS. Вот > это поворот! Оракле некомерсом назвали. Чего кого? В btrfs офлайн парсер, позволяющий к тому же потыкаться в разные точки входа - встроен в его родную утилсу. Прикольная идея, как по мне, хоть и жутко обидная для продавцов "клевых утилит" конечно - им всю малину обгадили. Как коммерческое решение то выкатывать если эти негодяи встроили фичу в тулкит файлухи сразу?! И это... btrfs проектировать по моему начали еще до того как оракл что-то там купил и закрыл, не? Там еще IBM был, и так далее. А реально - первой скрипкой пахал Крис Мэйсон, который состыковал ряд технологий в 1 дизайн. Никакие исходники никто никуда не переписывал - btrfs структурально основательно отличается, поэтому и может ряд вещей которые zfs'у слабо, типа смены схемы хранения на лету. И рефлинки там по моему с самого начала аж были. А не через ...цать лет да еще с багами убивающими пул, лол. ...а Кент вон вообще обошелся без работы в жирнокорпах. Десять лет упорного вджоба к своей цели - и купается в лучах заслуженной славы. Честнейше заработанной, между прочим.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (368), 27-Ноя-23, 10:36
	> btrfs проектировать по моему начали еще до того как оракл что-то там купил и закрыл zfs была открыта задолго до того как оракле понял, что она крута. :) Так что Крису было куда подглядывать помимо reiser и ext. Естественно, функции будут отличаться и структура тоже, ведь идёт адаптация под ядро, а они разные. Какие-то функции разработчику нравятся и он реализует по-своему, какие-то - нет, и он их отбрасывает. Главное - что у него есть куда подсматривать, чтобы не тормозить разработку. Вот попробуй сказать как работает динамический аллокатор в NTFS. Или какой там алгоритм определения сбойного блока? Или почему в UFS есть v-узлы, а в EXT от них избавились. Да смог бы ты вообще что-то сказать, не глядя в код или спецификацию. И я не говорю, что работа Криса - это мелочи. Нет, - это тоже тяжёлый труд. Но всё же он был сильно облегчён. Вон, в линуксе так навдохновлялись, что аж ошибка из солярки у них работает. Это возможно без её портирования в ядро? Хотя, это риторический вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	372. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 27-Ноя-23, 20:25
	>> btrfs проектировать по моему начали еще до того как оракл что-то там купил и закрыл > zfs была открыта задолго до того как оракле понял, что она крута.:) Оракл вообще купил в основном из-за соляры и явы как я понимаю, ну и чтобы энтерпрайзных клиентов перехватить. ZFS врядли был поводом, они ДО этого btrfs дизайнить начали. Очень странная идея затеять это - и потом скупить похожее. Хотя если теоретизировать что целью было убить конкурента (ZFS) это еще можно было бы понять, но дальнейшие действия и в эту идею тоже не вписываются. А в btrfs - спецом под всяких ораклов и их базы есть NOCOW. Эту фичу видимо оракл и ибм просили на двоих, для баз. А в zfs насколько я понимаю аналога этого как раз и нет? Ну а cow'ать базу идея так себе. Так что вот именно ораклу, именно zfs - куда? Они его и задвинули. > Так что Крису было куда подглядывать помимо reiser и ext. Подглядывать как сделан тот или иной дизайн - одно. Скопипастить код - другое. Да и на уровне структур - btrfs ну вот другой. И это специально. Вообще, достаточно продуманный дизайн, учитывающий траблы предыдущих. И попытавшийся их обойти. А также сделать менеджмент куда более приятным чем то что было до этого. Эта часть, имхо, неплохо получилась. > Естественно, функции будут отличаться и структура тоже, ведь идёт адаптация под ядро, У btrfs структура файлухи - не особо на ZFS похожа, как я понимаю. Он аллоцирует место на девайсах в юнитах "чанков" с той или иной "схемой хранения". Данные и метаданные могут иметь разную схему хранения, просто записываясь в разные чанки. И та или иная схема хранения, скажем, RAID1 формулируется как "записать это на 2 разные устройства". В такой формулировке не важно какая именно это пара девайсов, важно чтобы было 2 девайса с свободным местом, в их чанки с нужной схемой будет записано. Так можно сделать RAID1 из допустим 3 девайсов. И даже разной емкости. Вполне валидно и переживет отказ любого из девайсов. Хоть и выглядит как "зебра", но гарантии избыточности - остались. Это вроде достаточно специфично для btrfs и у остальных прямого аналога этого просто нет. Далее, CoW даже для метаданных - с специфичным респином b-tree под это. Это вообще хмыри из IBM придумали и уникально для btrfs. Экстенты. Zfs больше похоже на блочный дизайн на стероидах чем на экстенты. Btrfs вполне себе экстентная штука. Может потому и имеет сильно меньше проблем с рефлинками, которые были по моему аж изначально. Работа с снапшотами, subvolumes, вот это все - ну, это на zfs не похоже. > а они разные. Какие-то функции разработчику нравятся и он реализует по-своему, > какие-то - нет, и он их отбрасывает. Btrfs вроде изначально с ноля писан под семантику линукса и вон те пожелания. А то что в общие идеи дизайна подсматривали - ну да, в том числе уже и зная проблемы предшественников. ZFS очень уж специфичный дизайн, изначально включающий в себя что-то типа RAID-менеджера и управления буферами же. Нафига это все в линухе? От этого там только траблы. Кастомный "райд уровня ФС" еще понятно зачем, классическими способами ЭТО изобразить, с разными схемами хранения разных частей, и рестрайпом на ходу в что угодно, в прозрачном и довольно безопасном виде? Ну вообще никак. Так что какие-то идеи взяли, но в целом оно другой дизайн и другой код. Конечно учли опыт предшественников, особенно положительный. ...поэтому bcachefs можно условно обозвать Gen 3 cow'ов, если btrfs взять за Gen 2 а ZFS за Gen 1, ибо первые кто попробовал всерьез. Кенту то было видно проблемы и наработки предшественников, он тоже учел. Это и делает его штуку интересной. > Главное - что у него есть куда подсматривать, чтобы не тормозить разработку. > Вот попробуй сказать как работает динамический аллокатор в NTFS. Я так понимаю что большинство алгоритмов NTFS все же постепенно реверснули. И по крайней мере на уровне форматов расковыряно от и до. Но говоря за себя - глядя на то как NTFS работает с например 100К файлов в 1 дире - блин, пусть майкрософт себе супертехнологии и оставит. Даже btrfs его делает как с куста. А уж позор типа VSS и упоминать неудобно, на этом фоне снапошты btrfs просто космические технологии. Во всяком случае не ставит р@ком всю систему, делается моментально, и куда менее проблемное и кривое. > Или какой там алгоритм определения сбойного блока? Вот это уж точно малоинтересное знание. А чисто практически - btrfs у меня в вариантах с избыточностью здорово помог ремапу нескольких бэдов, своими self heal из другой копии. Данные проблемного сектора при этом как раз можно уже и не вычитывать - а фирмвари накопителей только этого и хотели, чтобы от сбойного сектора отстали и сделали туда запись. И тогда будет верификация, и если не получилось, то - ремап на резерв. Классика имеет свойство насиловать нечитаемый сектор до упора - данные же хочется. А если их нет... тогда оно постоянно ловит клин при попытке чтения этого файла, диры, ... - очень "удобно". А ремапнуть не могет - записи в проблемный сектор при этом не дождешься. > Или почему в UFS есть v-узлы, а в EXT от них избавились. Данное знание интересно только цифровым археологам, имхо. > Да смог бы ты вообще что-то сказать, не глядя в код или спецификацию. Сложный вопрос. Есть забавный эффект, если с чем-то возиться, приходит "ощущение области" и в целом понимание как можно, и как делают. При этом зачастую может получиться "угадать" или переизобрести. Поэтому ряд технологий могут оказаться "тем же самым, но сделаным иначе". Скажем bcachefs - в целом взял большую часть идей из btrfs. Но т.к. автору ряд вещей не нравился, немало идей постиг крутой респин - и сказать что это ripoff btrfs'а? Да ни в жизни, это совершенно новый дизайн, с иными решениями в ряде ключевых точек. Хоть и по мотивам, и хотящий такой же фичесет (снапшоты, рефлинки, сабволумы, похожее управление местом, ... ). Структурально аллокация сделана чуть иначе - chunk вроде бы нет. Есть более мелкие buckets, но по суммарному результату - что совой об пень, что пнем об сову. > И я не говорю, что работа Криса - это мелочи. Нет, - это тоже тяжёлый труд. Глядя на эту работу я вижу настоящего Архитекта. Он честно сделал свою часть, выкатив не хучший дизайн под известные ему требования и проблемы. И местами - весьма прикольно получилось. У ZFS это тоже есть, но оно настолько винтажное, специфичное для соляры и ее проблем, и покусаное энтерпрайзом, что мне сложно оценить этот дизайн по достоинству. Внутрях я хочу не того - а чего-то более универсального и масштабируемого. Крис и Кент меня в этом понимали намного лучше. > Но всё же он был сильно облегчён. Это несомненно, я думаю что странноватый дизайн ZFS связан с тем что это был первый или 1 из первых дизайнов, проблематика была еще не понята - и оперировали весьма урезанным пониманием. В этих допущениях оно наверное неплохо получилось. Но с тех пор много воды утекло. Много новых идей появилось. Много новых данных о проблематике. Это и побуждает новых архитектов пытаться выкатить новые дизайны. И последним писком является упрямый Кент, который попыхтев 10 лет всеж замайнлайнился - и теперь обречен пойти захватывать мир. Теперь поздно передумывать, выборы сделаны, дизайн создан, процессы запущены. > Вон, в линуксе так навдохновлялись, что аж ошибка из солярки у них работает. > Это возможно без её портирования в ядро? Хотя, это риторический вопрос. Так это в ZFS не работает, а не в линуксе. На минутку, ZFS не часть линукскернела. Это внешний модуль, и половина их проблем с новыми кернелами как раз из-за этого. ZFSники явно не успевают трекать эфолюцию блочного уровня кернела - и лажают! Чему пруфом прикольные баги в трекере с новыми ядрами, вплоть до дестроя пула. Btrfs и bcachefs такими проблемами не страдают. И рефлинки они между прочим умеют по моему с первой версии оба, bcachefs - точно, btrfs - ну я его в 2.6.32 все же не гонял, но когда он более 10 лет назад появился у меня, рефлинки уже точно были. И никаких проблем вот с именно этой фичой, или копированием/клонированием там файлов я не припоминаю. Этот детектив - фича ZFS. Не имеющая к линукс кернелу вообще никакого отношения - ибо ZFS там внешний модуль, и это его внутренние проблемы. Которые как я понимаю зацепили "всех кто юзал ZFS". Ну и линуксоидов с ним тоже. Экстраполировать это знание на именно Linux Kernel или другие файлухи в нем - ошибочная идея. На самых базовых уровнях. Они не используют ничего от ZFS, лицензия ZFS не позволяет. Так что в линухе эта шляпа живет совершенно отдельно, и разработчики там какие-то свои, отдельные. Их вообще не особо жалуют в майнлайне. И любые проблемы с внемайнлайновыми вещами вы вне майнлайна и решаете. Технически - это tainted kernel и никто из майнлайна не булет баги в нем изучать всерьез. Мало ли что чужие модули порушили. Поэтому любители внеядерных модулей, включая и ZFSников - выруливают со своими факапами как-нибудь сами.
	Ответить | Правка | Наверх | Cообщить модератору

	386. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 28-Ноя-23, 11:50
	> А уж позор типа VSS и упоминать неудобно, на этом фоне снапошты btrfs просто космические технологии. Во всяком случае не ставит р@ком всю систему, делается моментально, и куда менее проблемное и кривое. Ну кагбыда, но в реальной жизни почему-то нагруженный MsSQL под NTFS запустить можно - и даже консистентно забэкапить с использованием VSS получится, а вот с PostgreSQL на BTRFS - нууууэээээ... удачи, посоны!
	Ответить | Правка | Наверх | Cообщить модератору

	390. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (390), 28-Ноя-23, 19:26
	>> А уж позор типа VSS и упоминать неудобно, на этом фоне снапошты btrfs просто космические >> технологии. Во всяком случае не ставит р@ком всю систему, делается моментально, >> и куда менее проблемное и кривое. > Ну кагбыда, но в реальной жизни почему-т нагруженный MsSQL под NTFS запустить > можно - и даже консистентно забэкапить с использованием VSS получится, Мне вот интересно - чего такого "нагруженного" на вот именно MS SQL вообше запускают? Да и как VSS работает - я лично видел, так что можно не трудиться описывать мне эти космические технологии - been there, done that. > а вот с PostgreSQL на BTRFS - нууууэээээ... удачи, посоны! Ну если он реально нагруженный (это точно про россиян?) - nocow поставить и будет работать. Оракл ж не зря фичу для баз просил. А на нагруженому и так норм. Это компромиссы, конечно. И всегда можно накопать какое-нибудь дурацкое комбо. Меня вот больше парит допустим перфоманс при билдовке линукскернела. Как себя нтфс ведет на иерархии с 200-300К файлов? Ах, можно сказать что никак? А если в 1 диру столько сложить - то вообще хрен дождешься отображения этой диры в хоть там чем, от фара до эксплорера и каких там командеров? Черти что - зато с мс скулем. У которого условия использования так то сильно похуже постгра мягко говоря. Более жестко говоря, майки одно время давали халявную лафтовую версию - "мсскуль эмбедед" чтоли называлось. А потом всех с ней резко кинули. Не предоставив замену вообще, но обхяснив не лохам что - EOL. При том те кто юзал это - врядли хотели полный вариант со всеми прибабахами и требованием DBA впридачу.
	Ответить | Правка | Наверх | Cообщить модератору

	392. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 28-Ноя-23, 21:01
	> Мне вот интересно - чего такого "нагруженного" на вот именно MS SQL > вообше запускают? Да и как VSS работает - я лично видел, > так что можно не трудиться описывать мне эти космические технологии - > been there, done that. И вот эти вот конпелятели ядра и заменятели катриджей что-то там про enterprise admin говорят. За-ме-ча-тель-но. > Ну если он реально нагруженный (это точно про россиян?) - nocow поставить > и будет работать. Оракл ж не зря фичу для баз просил. > А на нагруженому и так норм. Это компромиссы, конечно. Ве-ли-ко-леп-но. И бэкап - агентом, через уровень приложения. И вот все у них так - "дезигн" великолепный, а как что практически применимое и в работе полезное даже не "сделать", а "повторить" - нет, я не про конпеляние ядер - за это в "энтерпрайзе" в общем не платят - упс! >[оверквотинг удален] > 200-300К файлов? Ах, можно сказать что никак? А если в 1 > диру столько сложить - то вообще хрен дождешься отображения этой диры > в хоть там чем, от фара до эксплорера и каких там > командеров? Черти что - зато с мс скулем. У которого условия > использования так то сильно похуже постгра мягко говоря. Более жестко говоря, > майки одно время давали халявную лафтовую версию - "мсскуль эмбедед" чтоли > называлось. А потом всех с ней резко кинули. Не предоставив замену > вообще, но обхяснив не лохам что - EOL. При том те > кто юзал это - врядли хотели полный вариант со всеми прибабахами > и требованием DBA впридачу. А теперь внимание, вопрос для энтерпрайз админов - что более востребовано в "энтерпрайзе типовом, резиновом" - помойка из 300к файлов ведра в одной дире, в которой даже полномочия вменяемо нарулить нельзя от лучших-в-мире-пингвиноводов - или вот этот вот самый иссык-куль?
	Ответить | Правка | Наверх | Cообщить модератору

	396. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Ноя-23, 22:00
	> И вот эти вот конпелятели ядра и заменятели катриджей что-то там про > enterprise admin говорят. За-ме-ча-тель-но. Я готов поспорить что корпы где я это все щупал были в фортуне-500 сильно выше вашей помойки (она вообще в фортуну 500 входит?). Так что я и смог насладиться шоу, так сказать, в первых рядах. Видок был шикарный, особенно с "embedded" версией и пофигизмом на жесткие баги в кишках виндов, голимый перфоманс операций и проч - но посмотрев на линуксоидов я заметил что можно работать и получше чем это. Ну и сменил род занятий - что я, помойка чтоли? Хочу работать с технологиями которые мне доставляют. Вон то - явно не оно. >> А на нагруженому и так норм. Это компромиссы, конечно. > Ве-ли-ко-леп-но. И бэкап - агентом, через уровень приложения. И вот все у > них так - "дезигн" великолепный, а как что практически применимое и > в работе полезное даже не "сделать", а "повторить" - нет, Ох, спасибо, имел я счастье с бэкапами мс-скуля. И очень рад что теперь все это - не у меня. Вместе с "офигенным" VSS и его чудным перфомансом. > я не про конпеляние ядер - за это в "энтерпрайзе" в общем не платят - упс! Ну я уже и не энтерпрайз, скорее что-то типа системного интегратора/эмбедера на вольных хлебах. С виндой я бы вообще такой номер повторить не взялся бы. Хреновая ось для кастомдева, и условия УГ, и апстрим проблемный. > А теперь внимание, вопрос для энтерпрайз админов - Вы так и не ответили на мой вопрос - где вам вообще активно юзаемый мс-скуль уперся, особенно чтоб еще и в РФии, или где вы там? (совдепа пытающегося в косплей энтерпрайзника за версту видно). Большинство кейсов использования мсскуля в РФ были откровенно высосаны из пальца - и являли собой развод на бабки нелохов, дабы попилить и откатить. Ну так, на правах наблюдений. Реально там не то что постгра, хватило бы и мускула в 90% случаев того что я видел. > что более востребовано в "энтерпрайзе типовом, резиновом" - Да мне похрен! Я не энтерпрайзы уже, и размахивать этим флагом перед моим носом бесполезно. > помойка из 300к файлов ведра в одной дире, в которой даже полномочия вменяемо > нарулить нельзя от лучших-в-мире-пингвиноводов - или вот этот вот самый иссык-куль? Между нами, впервые на характерный перфоманс нтфс я налетел именно в корпоративных условиях. Ну и лично мне не интересны энтерпрайзы на данный момент - нет никакого смысла делать этим мой мозг. Я как раз в альтернативах ZFS'а в виде btrfs и bcachefs очень приветствую масштабируемость и универсальность, для меня это аргумент за эти технологии а не ZFS, чрезмерно переклиненый на энтерпрайзных кейсах - в ущерб всему остальному. Такая ерунда.
	Ответить | Правка | Наверх | Cообщить модератору

	397. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (390), 28-Ноя-23, 22:06
	> И вот эти вот конпелятели ядра и заменятели катриджей что-то там про > enterprise admin говорят. За-ме-ча-тель-но. Я готов поспорить что корпы где я это все щупал были в фортуне-500 сильно выше вашей помойки (она вообще в фортуну 500 входит?). Так что я и смог насладиться шоу, так сказать, в первых рядах. Видок был шикарный, особенно с "embedded" версией и пофигизмом на жесткие баги в кишках виндов, голимый перфоманс операций и проч - но посмотрев на линуксоидов я заметил что можно работать и получше чем это. Ну и сменил род занятий - что я, помойка чтоли? Хочу работать с технологиями которые мне доставляют. Вон то - явно не оно. >> А на нагруженому и так норм. Это компромиссы, конечно. > Ве-ли-ко-леп-но. И бэкап - агентом, через уровень приложения. И вот все у > них так - "дезигн" великолепный, а как что практически применимое и > в работе полезное даже не "сделать", а "повторить" - нет, Ох, спасибо, имел я счастье с бэкапами мс-скуля. И очень рад что теперь все это - не у меня. Вместе с "офигенным" VSS и его чудным перфомансом. > я не про конпеляние ядер - за это в "энтерпрайзе" в общем не платят - упс! Ну я уже и не энтерпрайз, скорее что-то типа системного интегратора/эмбедера на вольных хлебах. С виндой я бы вообще такой номер повторить не взялся бы. Хреновая ось для кастомдева, и условия УГ, и апстрим проблемный. > А теперь внимание, вопрос для энтерпрайз админов - Вы так и не ответили на мой вопрос - где вам вообще активно юзаемый мс-скуль уперся, особенно чтоб еще и в РФии, или где вы там? (совдепа пытающегося в косплей энтерпрайзника за версту видно). Большинство кейсов использования мсскуля в РФ были откровенно высосаны из пальца - и являли собой развод на бабки нелохов, дабы попилить и откатить. Ну так, на правах наблюдений. Реально там не то что постгра, хватило бы и мускула в 90% случаев того что я видел. > что более востребовано в "энтерпрайзе типовом, резиновом" - Да мне похрен! Я не энтерпрайзы уже, и размахивать этим флагом перед моим носом бесполезно. > помойка из 300к файлов ведра в одной дире, в которой даже полномочия вменяемо > нарулить нельзя от лучших-в-мире-пингвиноводов - или вот этот вот самый иссык-куль? Между нами, впервые на характерный перфоманс нтфс я налетел именно в корпоративных условиях. Ну и лично мне не интересны энтерпрайзы на данный момент - нет никакого смысла делать этим мой мозг. Я как раз в альтернативах ZFS'а в виде btrfs и bcachefs очень приветствую масштабируемость и универсальность, для меня это аргумент за эти технологии а не ZFS, чрезмерно переклиненый на энтерпрайзных кейсах - в ущерб всему остальному. Такая ерунда.
	Ответить | Правка | Наверх | Cообщить модератору

	402. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от User (??), 29-Ноя-23, 07:51
	> Я готов поспорить что корпы где я это все щупал были в > фортуне-500 сильно выше вашей помойки (она вообще в фортуну 500 входит?). > Так что я и смог насладиться шоу, так сказать, в первых > рядах. Опыт замены катриджей офигенно релевантен вопросу, да. Уровень своих не "знаний", а "представлений" об даже не "крупном", а "среднем" бизнесе вы выше неоднократно замечательно продемонстрировали. > Видок был шикарный, особенно с "embedded" версией и пофигизмом на жесткие баги > в кишках виндов, голимый перфоманс операций и проч - но посмотрев > на линуксоидов я заметил что можно работать и получше чем это. > Ну и сменил род занятий - что я, помойка чтоли? Хочу > работать с технологиями которые мне доставляют. Вон то - явно не > оно. Рад за ваш карьерный рост - получение денег за самоудовлетворение вполне себе работа в наше время. > Ох, спасибо, имел я счастье с бэкапами мс-скуля. И очень рад что > теперь все это - не у меня. Вместе с "офигенным" VSS > и его чудным перфомансом. Меж тем, решения, которые есть и работают - на рынке в количестве, а вот восстановление одной базы в кластере postgres на момент времени - каждый раз неожиданно... увлекательная операция, хотя казалось бы. > Ну я уже и не энтерпрайз, скорее что-то типа системного интегратора/эмбедера на > вольных хлебах. С виндой я бы вообще такой номер повторить не > взялся бы. Хреновая ось для кастомдева, и условия УГ, и апстрим > проблемный. Еще раз - рад за ваш карьерный рост. Надеюсь, с донатами все ок? > Вы так и не ответили на мой вопрос - где вам вообще > активно юзаемый мс-скуль уперся, особенно чтоб еще и в РФии, или > где вы там? (совдепа пытающегося в косплей энтерпрайзника за версту видно). > Большинство кейсов использования мсскуля в РФ были откровенно высосаны из пальца > - и являли собой развод на бабки нелохов, дабы попилить и > откатить. Ну так, на правах наблюдений. Реально там не то что > постгра, хватило бы и мускула в 90% случаев того что я > видел. Ну, т.е. видели вы ровным счетом "нихрена", даже к мухами засиженной 1С и то не подпускали? Я понял. > Да мне похрен! Я не энтерпрайзы уже, и размахивать этим флагом перед > моим носом бесполезно. Вот совершенно не удивлен. Там за самоудовлетворение обычно не платят - требуют чего-то полезное делать, м-ммерзавцы. Еще и инструкции\требования со всех сторон, не развернуться непризнанному гению. > Между нами, впервые на характерный перфоманс нтфс я налетел именно в корпоративных > условиях. Ну и лично мне не интересны энтерпрайзы на данный момент > - нет никакого смысла делать этим мой мозг. А мне чужое самоудовлетворение не интересно, у меня вполне практические задачи, решать которые чьюдо-ФС помогают примерно "никак". > Я как раз в альтернативах ZFS'а в виде btrfs и bcachefs очень > приветствую масштабируемость и универсальность, для меня это аргумент за эти технологии > а не ZFS, чрезмерно переклиненый на энтерпрайзных кейсах - в ущерб > всему остальному. Такая ерунда. Ну вот как в дефолтах в RH или хотя бы Ubuntu Server (Ладно, и Astra Linux Special Edition сойдет!) появится - ну или там в вендорских рекомендациях какого-нибудь postgres pro всплывет - возвращайтесь. А пока - людям работать надо, а не вот это вот все мозолистыми руками наяривать.
	Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

	400. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Ноя-23, 02:41
	Давай пойдём от обратного. Я беру код ext4 и компилирую его (он же открыт, и компилятор имеется) для FreeBSD. Вопрос, я могу это сделать? Ведь по твоим личным убеждениям внешний модуль висит в воздухе ("в линухе эта шляпа живет совершенно отдельно"). А на слово "ядра" в словосочетании "модуль ядра" тебе плевать. Я отвечу. Нет не могу. Потому что я тупо взял чужой код, а не портировал его для FreeBSD. И он у меня просто не соберётся. Как я его должен портировать? Продолжай мысль. Куда писать код? А выше ты и сам сказал, что подглядывали. Так это и есть копипаста с рефакторингом. Поэтому разработчикам BtrFS не нужно было тратить долгие годы разработки на повтор функций из ZFS и ReiserFS. Они их скопировали с адаптацией. Копипаста, это не значит, что взяли чужой код и он сразу заработал. Так редко бывает даже на родственных системах. И когда ты смотришь в чужой древний код, это позволяет тебе избежать ошибок, совершённых другими разработчиками. Кто эти идеи вымучивал годами, а ты всего лишь реализовал под себя. И вместо благодарности старым не-GPL проектам, в линукс их объявляют "унтерменшами" в мире технологий и придумывают fашистские механизмы вроде EXPORT_SYMBOL_GPL. А потом ты и тебе подобные начинают их защищать словами "да вот там VSS... то, vnode... сё". Поэтому в BtrFS есть как функции из других систем, так и свои собственные, с учётом выявленных на других системах проблем. По той же причине BtrFS часто называют "heavily inspired". Причём не только ZFS. Если ты не понимаешь как ядро взаимодействует с модулями, и что в ядре для этого должно быть написано, то и не надо болтать ерунду про внешние модули. Модуль ядра это и есть часть ядра. Будет ли этот код скомпилирован модулем, решается на этапе конфигурации ядра. Другое дело, чтобы тебе скомпилировать ZFS немодулем ядра, это надо переименовать fашистский символ GPL (борющийся за чистоту расы, и чтобы остался только он один) в CDDL. При этом смешно читать как сами разработчика линукса отправляют желающих ZFS не модулем к разработчикам лицензий, оракле (ныне) и Столлману (который сам от своей лицензии заболел), или свалить на freebsd (ну это уже сам клоун Hellwig fашистствует). Ядро не будет взаимодействовать с модулем, если в нём нет кода для взаимодействия. А чтобы оно работало с подсистемой соляриса, оно должно быть портировано с соляриса с адаптацией под твоё ядро (линукс). Даже если это SPL, то есть - уже готовый слой портирования, линукс всё равно должно его подцепить и с ним работать. Но интересно: в линукс портировали из фряхи или с опенсоляриса. Линукс уже люди в переписке с разрабами клеймят за махинации с чужим кодом. Прямо говоря, что на деле в ядре символов (это термин) с GPL меньше, чем с другими лицензиями. И сравнивают системы на его базе с виндой (не в плане технологий). "To be frank, your argument, which boils down to "GPL is the only correct open source license", makes me ashamed to have been advocating people switching to Linux. This is exactly the kind of argument that made me switch away from closed source operating systems like Windows, only then it was Steve Ballmer using it against open source." Или вот это ещё лучше: "Because the GPL-only symbol export makes it seem like most symbols are NOT GPL-only. Why is there any distinction at all?" > Технически - это tainted kernel Так определись уже. Это вне ядра, или всё же ядро? А то у тебя противоречие. Правда уже понятно откуда. Ты не понимаешь что такое модуль ядра. Ничего там не tainted, это просто fашистская лицензия. А код нормальный. В других системах пользуются. Для tainted в линуксе есть конкретный флаг TAINT_PROPRIETARY_MODULE. Ну он и называется матерно в отношении GPL (там только тире не хватает), поэтому неудивительно. В общем, изучай, что такое портирование и как оно выполняется в ядро.
	Ответить | Правка | К родителю #372 | Наверх | Cообщить модератору

	30. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (30), 23-Ноя-23, 12:31
	Работает на серверах уже кучу лет, так что в надёжности можно не сомневаться. А нытье сколько угодно можно услышать практически про любую ФС начиная от fat и (ненужной и довольно ненадёжной, чтобы там не говорили виндузятники) ntfs, до ext (более чем надёжная, но и для неё есть культ плоскоземельщиков) и xfs ("оракл жи", а вот тут я и сам могу поныть, правда при весьма специфических условиях, но ведь вам не мешает ныть про ещё более специфические условия с zfs).
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	33. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (32), 23-Ноя-23, 12:35
	Просвяти на каких именно серверах и чем обусловлен выбор.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от BeLord (ok), 23-Ноя-23, 13:38
	Спроси у операторов большой тройки, что они сейчас используют-)))
	Ответить | Правка | Наверх | Cообщить модератору

	67. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 14:12
	> Спроси у операторов большой тройки, что они сейчас используют-))) Венду, венду и ... а, вот - венду!
	Ответить | Правка | Наверх | Cообщить модератору

	90. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (90), 23-Ноя-23, 14:29
	хоть новость бы дочитал "Повреждение файлов проявляется при достаточно редком стечении обстоятельств..."
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

	108. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Kuromi (ok), 23-Ноя-23, 15:47
	Вспомните про закон больших чисел. Есть ZFS будет на каждом ПК, то внезапно редкие обстоятельства станут не такими уж и редкими.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	145. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (7), 23-Ноя-23, 17:48
	Так наличие ZFS на компьютере - и есть то редкое обстоятельство.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 15:44
	Я понимаю, что по утру бзднуть хочется, но оглядываться все же не мешает https://openzfs.org/wiki/Companies
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–4 +/–
Сообщение от Аноним (3), 23-Ноя-23, 11:35
Ни на что не намекаю, но в Btrfs такой проблемы нет.
Ответить | Правка | Наверх | Cообщить модератору

	6. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+7 +/–
	Сообщение от Аноним (7), 23-Ноя-23, 11:40
	А какая есть?
	Ответить | Правка | Наверх | Cообщить модератору

	8. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–5 +/–
	Сообщение от Аноним (3), 23-Ноя-23, 11:42
	Ну например слишком стабильно работает, даже как-то скучно становится. Приходится искать, чем себя занять.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+6 +/–
	Сообщение от Аноним (9), 23-Ноя-23, 11:47
	Пишешь из будущего?
	Ответить | Правка | Наверх | Cообщить модератору

	28. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 12:31
	Из будущего альтернативной реальности - форкнулась где-то в 2010м. Там у них btrfs не только работает стабильно, но ее еще и не выкинули в пользу только что изобретенной новой поделки.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 00:41
	> Из будущего альтернативной реальности - форкнулась где-то в 2010м. Там у них > btrfs не только работает стабильно, но ее еще и не выкинули > в пользу только что изобретенной новой поделки. А зачем выкидывать то? Btrfs как раз до ума более-менее довели. А это только начинает свой жизненный цикл. И еще не умеет многое из. Допустим те же Zoned - кент там что-то еще только планирует накодить. И реверс-индексы для ускорения балансирования и проч - похваставшись перфомансом Кент заметил что btrfs его сажал не просто так, и когда начинает хотеться поменеджить - отсутствие реверс индексов (backrefs) почему-то, оказывается, воздается. Перфомансом менеджмент операций вида "бывает и получше, проверено btrfs'никами". И вообще, немного соревнования между командами - это то что доктор прописал, чтоб не зажирались и не тупили особо. А из редхата блочники/файлушники так и драпают. Даже уже и нонеймы какие-то утекать стали. Видимо при наличии таких цац идея пытаться догнать до этого уровня XFS выглядит не очень перспективно и получить пометочку FIRED в внезапном порядке при сокращении тимы по причине "хреново забивали микроскопом гвозди" - на любителя.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от glad_valakas (?), 23-Ноя-23, 12:36
	>  слишком стабильно работает а если нагрузить по методике Шишкина - что будет ? или: от чего там ntfs умирала - все помнят ?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	42. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (3), 23-Ноя-23, 13:05
	по той самой методике, которую он никому не раскрыл?
	Ответить | Правка | Наверх | Cообщить модератору

	131. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от glad_valakas (?), 23-Ноя-23, 17:07
	если подумать и поработать руками, то можно воспроизвести. задавшись вопросом "как быстро деградировать B-дерево, попутно нагадив в метаданные".
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (3), 23-Ноя-23, 17:19
	ну подеградируй, подеградируй мое дерево. Деградируй мое дерево полностью. Ты сможешь? Сможешь подеградировать мое дерево?
	Ответить | Правка | Наверх | Cообщить модератору

	269. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 24-Ноя-23, 13:58
	Меньше слушайте всяких экспертов Date    Fri, 18 Jun 2010 15:32:16 +0200 From    Edward Shishkin <> Subject    Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs https://lkml.org/lkml/2010/6/18/144 Проверяйте https://www.opennet.dev/openforum/vsluhforumID3/124332.html#419
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	376. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 27-Ноя-23, 23:53
	> https://lkml.org/lkml/2010/6/18/144 нашел время прочитать наконец-то... ахренеть, они несходящийся алгоритм ухитрились туда запихать? И оно вот до сих пор так?! (ну да, ну да, ежу понятно что ЭТО никак не могли переделать) > Проверяйте спасибо, чавойт не хочется. Скажите, а в разработке fs совсем нет вариантов вот чтоб без этого вот... ну то есть чтоб мог обычный васян а не докторская степень по математике? Я чисто спросить жеж...
	Ответить | Правка | Наверх | Cообщить модератору

	381. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 28-Ноя-23, 06:36
	> Скажите, а в разработке fs совсем нет вариантов вот чтоб без этого > вот... ну то есть чтоб мог обычный васян а не докторская > степень по математике? > Я чисто спросить жеж... Как Васян, наслышавшийся анекдотов про "у меня на виртуалке всё работает!", я не взялся бы за такое ни за какие коврижки. Ну, разве что как решение было бы допустимо тщательно изучить версию ZFS от Sun и под неё проектировать всё остальное ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	382. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 28-Ноя-23, 08:23
	>> Я чисто спросить жеж... > Как Васян, наслышавшийся анекдотов про "у меня на виртуалке всё работает!", я > не взялся бы за такое ни за какие коврижки. Ну, разве > что как решение было бы допустимо тщательно изучить версию ZFS от > Sun и под неё проектировать всё остальное ядро. Ну вы то с похом офигенные эксперты. Толи на ZFS осыпающемся, толи вообще на NTFS ажно. А у нас вот зато - на типовых сценариях работает (нет, е@нина с 600 меговой ФС забитой мелочью до отказа таковым не является, сюрприз!) - удобно в менеджменте - и вроде вот таких факапов в релизах не слуачается вроде, тьфу-тьфу. Особенно с такими детективами. Заодно и чистоплюи, вот, в другие локации отфильтровываются. Тоже неплохо.
	Ответить | Правка | Наверх | Cообщить модератору

	401. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (269), 29-Ноя-23, 05:24
	Ну ты то знаешь, зачем в ядре нужен префикс lock?
	Ответить | Правка | Наверх | Cообщить модератору

	201. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–2 +/–
	Сообщение от Аноним (202), 24-Ноя-23, 00:56
	>>  слишком стабильно работает > а если нагрузить по методике Шишкина - что будет ? Создать файлуху на 600 мегов и забить ее мелкотой? Можно, но вот что доказывает жалоба на то что межгалактический крейсер сложно на автопарковку втиснуть? Зачем его вообще туда? Пусть на орбите себе и висит, втираться на парковку - не его род занятий. Каким-то особым минусом этого дизайна сие не является. Ладно там еще Кенту который хочет заменять squashfs и явно козыряет компактностью структур это пенять, он сам напросился явной декларацией. > или: от чего там ntfs умирала - все помнят ? Создать том более 2 терабайт и посмотреть как оно себя протрет в ноль? На современных сторажах это уже давно протестировано, такие объемы уже не экзотика.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	177. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от lucentcode (ok), 23-Ноя-23, 21:59
	Уже много лет на btrfs, тьфу-тьфу, ни разу пока проблем не вылезло. Но, это не значит, что в каком-то будущем релизе что-то подобное не добавят.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	216. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (216), 24-Ноя-23, 02:08
	> Уже много лет на btrfs, тьфу-тьфу, ни разу пока проблем не вылезло. > Но, это не значит, что в каком-то будущем релизе что-то подобное > не добавят. Ну так... 1) btrfs интегрирован с майнлайном на тему разработки. 2) авторы оного еще и умеют в запуск тестов 3) кроме этого -rc ядра тестит довольно много народа в разных ипостасях. 4) откровенно экспериментальные фичи предпочитают честно называть таковыми. 5) разработчики фс явно наслаждаются тем что делают и горой за результат, насколько это к вон тем применимо - ахз.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от iZEN (ok), 26-Ноя-23, 12:16
	> А какая есть? Недообследованная.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	14. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
	Сообщение от Пряник (?), 23-Ноя-23, 11:49
	Текст в интернете всегда прав.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	113. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 15:58
	Да ну? А что ж тогда на редите приколоченные гвоздями проблемы весят
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	122. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (3), 23-Ноя-23, 16:23
	это ошибка выжившего. Когда бтрфс работает, никто не приколачивает гвоздями посты типа "прикиньте, у меня уже неделю ничего не происходит, все хорошо". Поэтому ты про это остаешься не в курсе.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 01:35
	> это ошибка выжившего. Когда бтрфс работает, никто не приколачивает гвоздями посты типа > "прикиньте, у меня уже неделю ничего не происходит, все хорошо". Поэтому > ты про это остаешься не в курсе. Так, я не про них, я про те что уже ОЧЕНЬ долго гвоздями прибиты
	Ответить | Правка | Наверх | Cообщить модератору

	245. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от YetAnotherOnanym (ok), 24-Ноя-23, 11:07
	Гораздо чаще встречается ошибка вдовы - "у меня сдохло, значит, у всех сдохнет".
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	348. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 17:14
	> Гораздо чаще встречается ошибка вдовы - "у меня сдохло, значит, у всех > сдохнет". товарищмайор, тут вдовроссии дискредитируют!
	Ответить | Правка | Наверх | Cообщить модератору

4. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+4 +/–
Сообщение от beck (??), 23-Ноя-23, 11:37
Продолжаем использовать ext4. Держите в курсе.
Ответить | Правка | Наверх | Cообщить модератору

	22. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (22), 23-Ноя-23, 12:10
	ntfs*
	Ответить | Правка | Наверх | Cообщить модератору

	307. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (307), 25-Ноя-23, 10:33
	fat16*
	Ответить | Правка | Наверх | Cообщить модератору

13. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от Аноним (13), 23-Ноя-23, 11:49
Шишкин прав был. Дерм..ще все эти ваши zfs, btrfs и т.п.
Ответить | Правка | Наверх | Cообщить модератору

	24. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+4 +/–
	Сообщение от Ахмат (?), 23-Ноя-23, 12:19
	FAT16 сила!
	Ответить | Правка | Наверх | Cообщить модератору

	26. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (26), 23-Ноя-23, 12:23
	Шишкин сила! Рейзер5 придет - порядок наведет!
	Ответить | Правка | Наверх | Cообщить модератору

	120. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от tim2k (ok), 23-Ноя-23, 16:12
	Ему же пожизненное дали?
	Ответить | Правка | Наверх | Cообщить модератору

	175. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
	Сообщение от Анонис (?), 23-Ноя-23, 21:40
	Файловой системе?
	Ответить | Правка | Наверх | Cообщить модератору

	217. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+4 +/–
	Сообщение от Аноним (216), 24-Ноя-23, 02:09
	> Ему же пожизненное дали? Шишкину то? Он конечно мерзкий зануда, но не настолько же?!
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	29. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (29), 23-Ноя-23, 12:31
	win95.cih с тобой не согласен ;)
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	154. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Анонимпс (?), 23-Ноя-23, 18:38
	Единственная файловая система которую Я осилил сам запрограммировать за свою жизнь :D Остальные просто не пробовал:)
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	68. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–3 +/–
	Сообщение от penetrator (?), 23-Ноя-23, 14:12
	btrfs - лучшая фс
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	96. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+6 +/–
	Сообщение от Аноним (96), 23-Ноя-23, 14:49
	Худшая из всех что тестировал.
	Ответить | Правка | Наверх | Cообщить модератору

	161. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 19:13
	zfs голимнее, вне майнлайна, тормозной, ресурсожоркий, управление куда кривее.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от penetrator (?), 24-Ноя-23, 08:06
	> Худшая из всех что тестировал. ога, тестировал он, во сне
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	160. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 19:12
	> Шишкин прав был. Дерм..ще все эти ваши zfs, btrfs и т.п. Ну он то как самый умный - не релизнул ФС вообще, reiser3 слил - нет файлух, нет проблем с ними. Все правильно сделал.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

19. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
Сообщение от еропка (?), 23-Ноя-23, 11:58
Ооооо, мне тут недавно один "специалист со стажем" расхваливал ZFS. Говорил, что конфетка а не фс. И что я глyпец, что на ext4 сижу
Ответить | Правка | Наверх | Cообщить модератору

	25. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (25), 23-Ноя-23, 12:21
	OpenZFS был основан и портирован говнокодер сообществом Linux. Не путать с Oracle ZFS от динозавров.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 16:02
	> OpenZFS был основан и портирован говнокодер сообществом Linux. Это эти то https://openzfs.org/wiki/Companies говнокодеры? Даже боюсь спросить, кого же вы тогда представляете... с таким авторитетным мнением, чтоб тех "говнокодеров" перебить
	Ответить | Правка | Наверх | Cообщить модератору

	152. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (153), 23-Ноя-23, 18:29
	Можно подумать там все эти компании что-то программируют. Они просто объединились в свой корпоративный синдикат, чтобы с важным видом обсуждать свои финансовые профиты, а для программирования могли нанять студентов на аутсорсе. А то компаний целый вагон, а минорный релиз и тот запороли, проглядев или добавив ошибку.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 19:27
	> Можно подумать там все эти компании что-то программируют. несколько штук таки есть. И да, это говнокодеры и саботажники. Начиная с дельфикс и "мы не можем исправить уже найденную и локализованную ошибку because luck of resources", продолжая iX не пожелавшими принимать готовый и вылизанный патч возвращающий memory pressure на протяжении трех лет и доломавших его совсем, а потом и вовсе выбросившей в помойку все наработки freebsd, и так далее. Остальное - собиратели гуанонасов из навоза и тому подобные мастера фуллшмяк программирования на пехепе.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 21:03
	> Начиная с дельфикс и "мы не можем исправить уже найденную и локализованную > ошибку because luck of resources", Такой прозрачный намек - "бабок хочется" :) > продолжая iX не пожелавшими принимать готовый и вылизанный патч возвращающий > memory pressure на протяжении трех лет и доломавших его совсем, а потом и вовсе > выбросившей в помойку все наработки freebsd, и так далее. Создали себе кучу головняка на ровном месте ZFSным "менеджментом кешей" живущим своей жизнью, и вот кто тут после этого - саботажник? Не те кто вопил что это так и надо, и срезал угол, впихав ЭТО прям так? Ну а теперь настало время отдавать техдолги. И это выглядит как-то так. Судя по всему технология попала в неправильные лапки, тем кто больше думает как $$$ срубить. А если для этого корову (cow) надо на мясо - ну, значит так тому и быть. И пофиг что разовая акция.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 01:40
	> Они просто объединились в свой корпоративный синдикат, чтобы с важным видом обсуждать свои финансовые профиты Это вам баб Маша в подьезде сказала? > а для программирования могли нанять студентов на аутсорсе. Кто? Амазон студентов на аутсорсе? Я здесь много телепатов видел, но вы - самый уникальный !
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	240. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 24-Ноя-23, 09:57
	А из того списка только амазон пашет? Это обычная практика в наше время. Опытный сотрудник не хочет делать работу и заказывает голодного фрилансера. И почему бы амазону не нанимать студентов. https://devby.io/news/amazon-budet-nanimat-na-pozitsii-inzhe... К тому же, не обязательно амазон создал проблему.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 12:30
	Т.е. для тебя без 5-ти минут инженер и фрилэнцер - одно и тоже? И на то, что работает в проде бросать даже интернов - это только в опеределленых недоразвитых уголках планеты судя то твоей заяве разрешается
	Ответить | Правка | Наверх | Cообщить модератору

	263. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 24-Ноя-23, 13:30
	> Т.е. для тебя без 5-ти минут инженер и фрилэнцер - одно и > тоже? конечно нет - первый вообще ничего не умеет, а второй - ну хз, кто это. > И на то, что работает в проде бросать даже интернов - это > только в опеределленых недоразвитых уголках планеты судя то твоей заяве разрешается просто интерны дешевле именно в этих недоразвитых уголках. А современное развитие рабовладения позволяет их из этой задницы мира даже и не вывозить, прямо там и веслают. В принципе, весь твой современный массовый прод именно так и написан.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 24-Ноя-23, 13:35
	Я и сам таким был когда-то. А в амазоне работают такие же люди, которых сейчас в угоду ии сокращают пачками. То есть амазоновский инженер оказался тупее чатаджипити. А он дорогой, зараза. А студент дешёвый и выделываться не будет. Сколько новостей уже было типа "заказал работу фрилансерам и уехал отдыхать", "получал премии за чужую работу". И если я правильно помню, работник был из такого недоразвитого уголка планеты как то ли сша, то ли канады. Ничего такого в этом нет, это современное делегирование рутины.
	Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

	304. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 25-Ноя-23, 07:29
	> Сколько новостей уже было типа "заказал работу фрилансерам и уехал отдыхать", "получал премии за чужую работу". Ну, теперь понятен уровень осведомленности о устройстве амазона :) Читайте дальше новости, и главное - верьте !
	Ответить | Правка | Наверх | Cообщить модератору

	305. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 25-Ноя-23, 09:49
	> Ну, теперь понятен уровень осведомленности о устройстве амазона :) > Читайте дальше новости, и главное - верьте ! Твой источник новостей про самоотверженное кодирование zfs #тыжбез5минутинженер-ом-из-амазона чем-то отличается от источника одна-бабка-сказала? Я тебе показал, что такое возможно. Всего лишь. Ты же сделал себе из амазона икону и начал сочинять небылицы про то, чего никогда не видел. Ладно бы ты там работал, но из пятёрочки грузчиков в амазон наверное пока не набирают.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 25-Ноя-23, 18:28
	> про то, чего никогда не видел. Видел, потому и говорю > Ладно бы ты там работал, но из пятёрочки грузчиков в амазон наверное пока не набирают. Легче стало? Хороших выходных!
	Ответить | Правка | Наверх | Cообщить модератору

	241. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 24-Ноя-23, 10:01
	А у амазона нет своей корпоративной почты? Что-то в этом списке их нет. https://github.com/openzfs/zfs/blob/master/AUTHORS
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	256. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 12:44
	> А у амазона нет своей корпоративной почты? Там где идет речь о FSx, то изпользуется корпоративная почта, иначе слишком много легальных акул, чтоб рисковать
	Ответить | Правка | Наверх | Cообщить модератору

	266. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 24-Ноя-23, 13:40
	> Там где идет речь о FSx, то изпользуется корпоративная почта FSx - это амазоновское корпоративное решение поверх openzfs. То есть для общей разработки zfs они ничего не делают, только подгоняют под свои облака.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 14:46
	>  То есть для общей разработки zfs они ничего не делают, только подгоняют под свои облака. Ох уж эти телепаты... Для того, чтобы мыши прибегали на сыр, - он должен быть сьедобным, иначе все затраты на внедрение нового продукта не оправдаются, именно поэтому корпорации заинтересованны во всем, что в спросе и чтоб оно не сдохло быстро
	Ответить | Правка | Наверх | Cообщить модератору

	278. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (262), 24-Ноя-23, 16:53
	Ух ты. Так сыр, оказывается, несъедобный. И поэтому они на его базе своё решение запилили. Достойная опеннета логика. И часто применяемая в обсуждениях со стороны линуксоидов. Впрочем, конкретно эти гадания, кто там что делает, не столь интересны как сабж.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 25-Ноя-23, 07:24
	> Ух ты. Так сыр, оказывается, несъедобный. ??? Закусывать надо
	Ответить | Правка | Наверх | Cообщить модератору

	325. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (319), 26-Ноя-23, 01:28
	>> Ух ты. Так сыр, оказывается, несъедобный. > ??? Закусывать надо Так он и закусил, видимо, "живу плохо: вино кислое, сыр плесневелый, машина без крыши..."
	Ответить | Правка | Наверх | Cообщить модератору

	181. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от NetGhost (?), 23-Ноя-23, 22:49
	Не Oracle ZFS а Sun ZFS. Оракул того и гляди закопает эту ФС
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	27. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от rinat85 (ok), 23-Ноя-23, 12:30
	я один из таких :D очень жду bcachefs но пока где можно всюду zfs. Неделю эксплуатирую зеркало на 2ТБ как раз на zfs 2.2, под podman хост в lxc контейнере, bclone никак не задействован, ошибок нет. Не то, чтобы сильно защищаю, это всё плохо, но вообще эта проблема проявляется при нагромождении факторов и в основном с версией 2.2 с её bclone фичей, которая релизнулась всего месяц назад, у кого-то при использовании ZFS 2.1 поверх LVM2 (что в общем-то не запрещается, но некоторое дублирование функционала выходит), в серьезном продакшн версию 2.2 точно рановато использовать, Proxmox собираются одновременно с переходом на linux 6.5 где-то в декабре, но только на бесплатном полутестовом репозитории.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	36. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (32), 23-Ноя-23, 12:37
	О каком серьёзном продакшне речь? Как ни спросишь - оказывается либо подкроватный сервак, либо proxmox.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от turbo2001 (ok), 23-Ноя-23, 12:53
	Hetzner в своём storage box использует zfs. Это достаточно серьёзный продакшн или ещё нет?
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (129), 23-Ноя-23, 13:14
	Понятия не имею. Хочется рабоче-крестьянского чёткого объяснения - мы используем там-то и потому-то. А то как у бсдшников получается - сплошные баззворды, нетфликс, сони, бла бла. А потом выясняется, что серьёзный продакшн - это качалка торрентов.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+4 +/–
	Сообщение от Аноним (9), 23-Ноя-23, 14:20
	Рабоче-крестьянский слив защитан
	Ответить | Правка | Наверх | Cообщить модератору

	89. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от turbo2001 (ok), 23-Ноя-23, 14:28
	Из того, что наружу торчит - используются снапшоты и квоты (с учетом снапшотов). Могу предположить, что дедупликация и сжатие тоже нужно для снижения себестоимости услуги. Это приводит к выбору между btrfs и zfs, они выбрали последнее.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	132. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (129), 23-Ноя-23, 17:07
	Да причём тут "они"? Я спрашиваю лично серьёзные-продуктовики в этом треде как используют? Простой вопрос же. Кроме соплей веером и "вот у них то уххх!" у вас ничего нет)
	Ответить | Правка | Наверх | Cообщить модератору

	140. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от 1 (??), 23-Ноя-23, 17:35
	Господи ... Что для Вас означает "серьёзные-продуктовики" ? Ну вот мы отнюдь не "серьёзные-продуктовики". У нас стоит NetApp, дорада от плохого пути, парочка инфотрендов и пара emc. Ну а что у них внутре - ХЗ. А с ZFS я играюсь на TrueNAS на SuperMicro ... Там у меня бакап бакапов бакапов ...
	Ответить | Правка | Наверх | Cообщить модератору

	260. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 24-Ноя-23, 13:07
	> Ну вот мы отнюдь не "серьёзные-продуктовики". У нас стоит NetApp, дорада от > плохого пути, парочка инфотрендов и пара emc. Ну а что у > них внутре - ХЗ. в netapp - по многим источникам таки какой-то свой клон zfs. Вплоть до появлявшихся предложений официальных сотрудников нетапа кое-что бэкпортировать оттуда сюда. ;-)
	Ответить | Правка | Наверх | Cообщить модератору

	267. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от 1 (??), 24-Ноя-23, 13:43
	Да на своём клоне FreeBSD свой клон ZFS.
	Ответить | Правка | Наверх | Cообщить модератору

	321. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 26-Ноя-23, 00:24
	> Да на своём клоне FreeBSD свой клон ZFS. Проприетарщики они такие. А как апстрим в результате сдохнет и придется волочь на себе вообще совсем все - так они и пойдут искать к чему бы еще присоседиться.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 16:05
	> Хочется рабоче-крестьянского чёткого объяснения - мы используем там-то и потому-то. https://openzfs.org/wiki/Companies Достаточно ? Или нужно по кестьянски обяснить, что бизнесы просто так баблом не раскидываются
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	133. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (129), 23-Ноя-23, 17:09
	>Достаточно Нет. Гуглом я умею пользоваться. Вопрос в другом. >нужно по кестьянски обяснить, что бизнесы просто так баблом не раскидываются Обьясни, пожалуйста. Я последние 10 лет в бизнесе, вдруг не знаю чего.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 01:37
	> Обьясни, пожалуйста. Я последние 10 лет в бизнесе, вдруг не знаю чего. Бизнес - это про профит. Если ты еще этого еще не понял, то я не верю что ты в бизнесе.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от rinat85 (ok), 23-Ноя-23, 12:58
	> О каком серьёзном продакшне речь? Как ни спросишь - оказывается либо подкроватный > сервак, либо proxmox. Если рассуждать так, то всё равно даже начиная от небольшой организации в 50 сотрудников отвечать за сохранность сервисов, файловых хранилищ, БД, тоже надо, и даже с этого уровня не будешь разворачивать или обновлять функционал файловой системы до версии, которая вышла всего-лишь месяц назад. Proxmox упомянул, потому что в тестовой среде у меня очередной, да и неплох как простой гипервизор под несложные инсталляции, где не надо ни кластеров больших, ни реального объединения ресурсов, банально чтобы избежать bare metal. Если ваш уровень это уровень облачного провайдера, поздравляю с успешной карьерой, но продакшн он когда и небольшой всё равно серьёзный ;)
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	45. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (129), 23-Ноя-23, 13:19
	>небольшой организации в 50 сотрудников Больше ничего можно было не писать, спасибо. Как я и говорил - "наш программист поставил нам 1С на сервер". >продакшн он когда и небольшой всё равно серьёзный ;) Смайлик ты совершенно верно поставил. Потому что в таком серьёзном продакшне ты можешь использовать вообще что угодно, хоть ntfs. Никто разницы не заметит. Это называется "необоснованный выбор".
	Ответить | Правка | Наверх | Cообщить модератору

	101. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
	Сообщение от rinat85 (ok), 23-Ноя-23, 15:23
	> Потому что в таком серьёзном продакшне ты можешь использовать вообще что угодно, хоть ntfs. Никто разницы не заметит. Это называется "необоснованный выбор". О, великий, снизошёл! :) Даже на таком уровне... Возможность собрать надежные зеркала (без привязки к дорогим железным рэйдам): нужна Чек-суммы: нужны Снапшоты:  нужны Быстрый инкрементальный и очень частый бэкап: нужен SMB отрабатывают весь спектр настройки прав доступа, который необходим: нужно Возможность тюнинга volblock и dataset исходя из сценария использования: нужна Даже в редком случае внезапного отключения (что-то с ИБП) быстрое восстановление без нескольких минут ожидания в случае ntfs и порой десятков секунд fsck: полезно ZFS прекрасно выполняет свои функции, более того, на ZFS 2.2 можно обновить на уровне пакетов текущие инсталляции даже в проде, всего-лишь не делая апгрейда самих файловых систем до структуры 2.2, часто так и делают, если нет необходимости в новых функциях, а если есть, то перед апгрейдом мало-мальски разумный админ протестирует отдельно и проверит бэкапы.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (104), 23-Ноя-23, 15:33
	> ыстрый инкрементальный и очень частый бэкап: нужен Есть ощущение, что под словом "бэкап" вы понимаете что-то не то.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от rinat85 (ok), 24-Ноя-23, 00:46
	>> ыстрый инкрементальный и очень частый бэкап: нужен > Есть ощущение, что под словом "бэкап" вы понимаете что-то не то. Нет, есть ощущение, что вы думаете, будто я путаю бэкапы со снапшотами. Уже ответил на это кому-то, повторюсь: "Я про снапшоты написал отдельно, и про бэкапы отдельно, вы же решили почему то, из-за слов об инкрементальном частом и быстром бэкапе, что я говорю о снапшотах. Вовсе нет, для файловой хранилки есть прекрасные обертки поверх механизма send/receive (например zrepl), и бэкап у меня именно что бэкап в другое здание"
	Ответить | Правка | Наверх | Cообщить модератору

	138. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (129), 23-Ноя-23, 17:24
	Да я с тобой не спорю, ты в самом начале своего пути, очень многое узнаешь позже. Например, что в твоём любимом серьёзном продакшене никто не бекапится снапшотами ФС. А есть специальные вещи, которые называются система резервного копирования, ленточные библиотеки, агентский бэкап и т.п. То что рассказываешь ты - это требования к ноутбуку в школе на информатике.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	196. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от rinat85 (ok), 24-Ноя-23, 00:41
	> Да я с тобой не спорю, ты в самом начале своего пути, > очень многое узнаешь позже. Например, что в твоём любимом серьёзном продакшене > никто не бекапится снапшотами ФС. А есть специальные вещи, которые называются > система резервного копирования, ленточные библиотеки, агентский бэкап и т.п. То что > рассказываешь ты - это требования к ноутбуку в школе на информатике. Простите, сударь, а вы можете внимательно читать? Я про снапшоты написал отдельно, и про бэкапы отдельно, вы же решили почему то, из-за слов об инкрементальном частом и быстром бэкапе, что я говорю о снапшотах. Вовсе нет, для файловой хранилки есть прекрасные обертки поверх механизма send/receive (например zrepl), и бэкап у меня именно что бэкап в другое здание.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (7), 23-Ноя-23, 17:52
	> Быстрый [...] и очень частый бэкап: нужен Всё, что нужно знать о ZFS.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	193. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (30), 24-Ноя-23, 00:15
	Как говорится пользователи делятся на два вида: те кто использует zfs и те кто пока не используют.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от rinat85 (ok), 24-Ноя-23, 00:44
	>> Быстрый [...] и очень частый бэкап: нужен > Всё, что нужно знать о ZFS. Что нужно делать бэкапы? Ну да, нужно, а где не нужно? ZFS в рамках своего функционала позволяет делать именно частые бэкапы, у меня изменения за каждые 10 минут отправляются на бэкап сервер, тут что-то не так?
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	54. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 23-Ноя-23, 13:46
	Это какой-то новый вид технического постироничного стендапа?
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	162. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 23-Ноя-23, 19:15
	> я один из таких :D очень жду bcachefs но пока где можно всюду zfs. Оно уже в -rc 6.7, так что самое время потестировать на своих нагрузках. И кстати пока на нее компромата - меньше чем на вот это вот нашлось. Такая ерунда.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

20. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от Аноним (104), 23-Ноя-23, 12:05
Да ну, не может быть такого. Вон пох (или нах? я их путаю) вчера же разъяснил - во всем виноваты арчеводы и прочие гентушники, компиляющие свои ядра как ни попадя, с наподвыпереломанными интерфейсами. > ошибку удалось воспроизвести во FreeBSD Вон докуда гентушники окоянные дотянулись
Ответить | Правка | Наверх | Cообщить модератору

	39. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от glad_valakas (?), 23-Ноя-23, 12:48
	вы будете смеяться, но когда я подбирал себе дистрибутив линукса, рекомендации для мигрантов с freebsd были такие: "arch linux или gentoo". gentoo я посмотрел и не осилил, остался только arch.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (153), 23-Ноя-23, 13:40
	gentoo - как фряха из портов arch - как фряха из пакетов Не самые плохие рекомендации.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (104), 23-Ноя-23, 15:27
	Вот видишь. А промолчал бы про бсд - глядишь, посоветовали бы какой-нибудь минт, и жил бы себе припеваючи
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	318. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (318), 25-Ноя-23, 22:54
	> подбирал себе дистрибутив Смотр зачем. Я п Арч не выбрал. Слишком много и часто возиться надо из-за обновлений...
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

31. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
Сообщение от Аноним (30), 23-Ноя-23, 12:34
Если проблему можно воспроизвести, то почему не найдут регресс через git bissect (это может не так просто, но вопрос времени, а не возможностей), а найдя коммит уже можно его препарировать
Ответить | Правка | Наверх | Cообщить модератору

	37. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 12:39
	потому что ее можно воспроизвести только с определенной долей вероятности. И вопрос времени - очень конечно хорош для рептилоидов, с их сроком жизни в полторы тыщи лет можно никуда не спешить, а для остальных так себе. И вероятнее всего это не один комит, а целая пачка сделаных в разное время, вытащивших проблему на поверхность. Как же за...ли каргокультисты. Один в bisect верует, второй в blame... вызубрили три ненужных  заклинания гита и успешно применяли на своем хеловроте (нет, конечно же, нет. Просто вызубрили.)
	Ответить | Правка | Наверх | Cообщить модератору

	92. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:35
	Не, вот этот вот бисекс приятно работает в их вырожденном случае игр-однодневок и около, когда ошибка у одного землекопа вот в этих вот 50 строчках, которые конкретно вот этим вот юнит-тестом покрываются. А в сложных многоуровневых системах всё верно, пачка коммитов, и вообще возможно разные лишь косвенно связанные модули. + ошибка не в логике, а во взаимодействии с редким определённым набором данных - никакие юнит-тесты не помогут. Короче, всё так.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–3 +/–
	Сообщение от Аноним (30), 24-Ноя-23, 00:48
	Сколько философов то развелось. Сами в жизни больших и сложных систем не видели иначе бы не писали такую ерунду: что пачка, что один коммит - совершенно не важно, раньше вообще флоу были по месячным, а то и годовым релизам, это сейчас фичаветки в основном используют; и тогда и сейчас искали точно также как делает бисект, только вручную; что ошибка в логике, что в интеграции, что в данных, что в одном коммите, что в пачках - если проблема воспроизводится, то бисект найдёт на каком изменении она появилась. Ну а вы дальше философствуйте о бесполезности юнит тестов, которые кстати и проблемы с некорректными данные находить могут через фаззинг тестирование.
	Ответить | Правка | Наверх | Cообщить модератору

	270. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 24-Ноя-23, 14:20
	"When in doubt, use brute force." Кен Томпсон тоже не видел больших систем.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 16:51
	> Кен Томпсон тоже не видел больших систем. Увы. Боюсь что только системный (есть еще юзерленд) код zfs больше чем все то что он за всю жизнь написал сотоварищи. Компьютеры тогда были - большие. А вот память - нет.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (30), 24-Ноя-23, 00:30
	> потому что ее можно воспроизвести только с определенной долей вероятности Похоже на твои домысли. В новости например про это ни слова. > И вероятнее всего это не один комит, а целая пачка сделаных в разное время, вытащивших проблему на поверхность. Так bisect и создан чтобы найти когда твои коммиты выстроились в ряд. > Как же за...ли каргокультисты. Один в bisect верует, второй в blame... вызубрили три ненужных  заклинания гита и успешно применяли на своем хеловроте (нет, конечно же, нет. Просто вызубрили.) Это тебе твоё чутье ванги подсказало как и с воспроизведением бага?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	277. Скрыто модератором	+/–
	Сообщение от Аноним (30), 24-Ноя-23, 15:48
	https://github.com/openzfs/zfs/issues/15526#issuecomment-182... Это все что нужно знать про комментарии nox'a
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	339. Скрыто модератором	+/–
	Сообщение от пох. (?), 26-Ноя-23, 16:56
	> https://github.com/openzfs/zfs/issues/15526#issuecomment-182... > Это все что нужно знать про комментарии nox'a это все что нужно знать про экспертов опеннета. Т.е. чувак нашел своим бесполезным умением в еще две команды гита - ровно то о чем все и без него знали - в каком комите появилась фича с next_sync=1. К сожалению, это ничем не помогло понять где на самом деле ошибка и как ее исправлять. О чем бы ты мог догадаться, поглядев следующие стопиццот записей в этом же issue. Но это сложна и многабукав, вот жеж - шитсект, слово знакомое. "136 hidden items" следом можно и не открывать (не тратьте клик - не нашли). Уровень опеннета. Полагаю что таков уровень рассиянской ит в целом.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-23, 01:05
	> Если проблему можно воспроизвести, то почему не найдут регресс через git bissect > (это может не так просто, но вопрос времени, а не возможностей), > а найдя коммит уже можно его препарировать Ну, узнаете вы что это имплементация рефлинков косячная. И?! Даже если вы зафиксите 1 баг - есть уверенность что еще 5 новых таких же нет? А если посмотреть на их гитхаб... вашу ж 20. Там 1.1К открытых багов. И эти люди быкуют на btrfs, его пригодность к продакшну и проч. О..ть!
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	246. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 24-Ноя-23, 11:20
	> Ну, узнаете вы что это имплементация рефлинков косячная. И?! и просто отключаешь эту фичу и живешь счастливо (восстановив пул из бэкапа, потому что оно не отключается на существующем). Но, к сожалению, маловероятно. Поэтому там где данные представляют существенную ценность - не надо пользоваться реализацией openzfs. В остальных случаях - выбирают меньшее из зол (например, storage spaces ;-) > Там 1.1К открытых багов. И эти люди быкуют на btrfs, его пригодность к продакшну и проч. безусловно отсутствие у btrfs полноценного гитхаба и списка открытых багов говорит о его пригодности к продакшну и проч, а не о том что линукс и его разработка давным-давно полная помойка застрявшая в начале 90х, где баги надо искать среди миллиарда писем в lkml оставленных без ответа или с парой тысяч комментариев не по теме.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 18:06
	> и просто отключаешь эту фичу и живешь счастливо (восстановив пул из бэкапа, > потому что оно не отключается на существующем). Но, к сожалению, маловероятно. Когда возникают вопросы вида "восстановив пул из бэкапа" я рад что все это - не у меня :)) > выбирают меньшее из зол (например, storage spaces ;-) Кому попадья, кому свиной хрящик, как грится. > безусловно отсутствие у btrfs полноценного гитхаба и списка открытых багов говорит о > его пригодности к продакшну и проч, У них нормальная багзила. Хорошо работает - берут в оборот не дожидаясь накопления 1К багов. Мля, когда тебе кило багов насыпали, глаза будут в кучку и ты не будешь знать за что схватиться. Но ты конечно можешь мне рассказать как это делать правильно. Есть только 1 нюанс - я в мегакорпах в R&D был и получше твоего в курсе, так что удачи. > а не о том что линукс и его разработка давным-давно полная помойка застрявшая в начале 90х, > где баги надо искать среди миллиарда писем в lkml оставленных без > ответа или с парой тысяч комментариев не по теме. Да вообщет там багзила есть. Для увеличения эффекта она дублирует и письмом в LKML. Но тебе то простительно не знать. Из тебя линукс разработчик, который -next от mainline отличить не может блин. Только и остается что на гитхабе колупаться, еще патчи начни через вебредактор им присылать(не помню, есть он уже на гитхабе?). Так победите! (самих себя, кстати) А знаешь в чем разница? Я суммарно навесил - и мы потом сообща загасили - сколько-то десятков багов в Linux Kernel. Конкретно btrfs'ники были крайне эффективны. В том числе и через тот интерфейс. Так что все баги которые я им навешивал уже давно -> closed. Мне кажется такое состояние дел способствует чтобы их 1K не было. Впрочем они научились гонять дофейхоа тестов - а если этого мало оказалось - то - вот - в -rc толпа еще дополнительно тестирует более странные вещи.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 26-Ноя-23, 01:22
	> и просто отключаешь эту фичу и живешь счастливо (восстановив пул из бэкапа, > потому что оно не отключается на существующем). Судя по довеску к новости - это кажется не поможет, а факап возможно был и раньше. А вы думали, кило багов в багтреке - дым без огня? Наивные какие.
	Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

	276. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (30), 24-Ноя-23, 15:47
	Скорее всего узнаю только на каком изменении баг появился. Но этого достаточно чтобы просмотреть изменяемые структуры и дебажить только их. Наличие других багов не повод вообще не править баги.
	Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

	279. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 17:47
	> Скорее всего узнаю только на каком изменении баг появился. Но этого достаточно > чтобы просмотреть изменяемые структуры и дебажить только их. Да в принципе вы правы. Но судя по тому что я в багтреке увидел, проблема идет несколько дальше чем только это. Такое ощущение что фичу вообще не тестили - а в багтреке дофига и иных крутых багов. На которые всем более-менее пофиг. > Наличие других багов не повод вообще не править баги. Вот это бесспорно.
	Ответить | Правка | Наверх | Cообщить модератору

	340. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 16:58
	> Ну, узнаете вы что это имплементация рефлинков косячная. И?! Даже если вы Мы уже узнали что нет, не она. Она помогла наткнуться на баг, который где-то непонятно где. > Там 1.1К открытых багов. И эти люди быкуют на btrfs, его пригодность > к продакшну и проч. О..ть! действительно. нет бы позакрывать с wontfix первые 1k хотя бы.
	Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

	355. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 27-Ноя-23, 01:00
	>> Ну, узнаете вы что это имплементация рефлинков косячная. И?! > Даже если вы Мы уже узнали что нет, не она. > Она помогла наткнуться на баг, который где-то непонятно где. Да вообще, детектив целый получился. По своему интересный, но к счастью, не у меня. Впрочем, поразвлекавшись с дизайном кента я таки нашел детектив не сильно хуже и для себя. Отличие? Там меня честно и явно предупредили что вон та фича - просто супер-экспериментальная. В таком то виде - без претензий за квест. >> Там 1.1К открытых багов. И эти люди быкуют на btrfs, его пригодность >> к продакшну и проч. О..ть! > действительно. нет бы позакрывать с wontfix первые 1k хотя бы. Добрый ты - всегда подскажешь как проекту репутацию максимально круто и быстро слить :). Это было бы конечно презабавнейшее шоу, но - не советую. Конечно потанцевать на могилке иной раз - тоже забавно, но если конкуренции в мире станет меньше, это будет loss-loss для нас обоих. А за такие маневры можно и доиграться по линии репутации вообще совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	273. Скрыто модератором	–1 +/–
	Сообщение от OpenEcho (?), 24-Ноя-23, 14:42
	> Если проблему можно воспроизвести, то почему не найдут регресс через git bissect "Они вас услышали" :) ошибка вкралась на  commit in ZFS 2.1.4 https://github.com/openzfs/zfs/issues/15526#issuecomment-182... А вообще для любого действия требуется время, блэймить то все мастера, а вот делать - это другое
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	341. Скрыто модератором	+/–
	Сообщение от пох. (?), 26-Ноя-23, 16:59
	>> Если проблему можно воспроизвести, то почему не найдут регресс через git bissect > "Они вас услышали" :) ошибка вкралась на  commit in ZFS 2.1.4 нет :-/
	Ответить | Правка | Наверх | Cообщить модератору

	349. Скрыто модератором	+/–
	Сообщение от OpenEcho (?), 26-Ноя-23, 17:49
	> нет :-/ :(
	Ответить | Правка | Наверх | Cообщить модератору

38. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+8 +/–
Сообщение от Аноним (104), 23-Ноя-23, 12:46
Ы На гитхабе https://github.com/openzfs/zfs/pull/15529 два девелопера спорят, отключать эту фичу по умолчанию или нет: - если задизаблим brt, она никогда не будет готова! - да погоди, я думаю, потестить бы надо? - да как же мы ее потестим, если она задизаблена? - эээ... вообще-то нормальные люди тесты пишут для новых фич, прежде чем выкатывать фичи в стабильный релиз? (окружающие замерли, пораженные свежестью и новизной этой мысли) И чуть дальше "Presently, there's a few tests that Klara added months after the feature was integrated, that are all Linux-only as of this writing, and only exercise a limited number of things each, and as remarked above, FreeBSD had this feature disabled in its development releases until a few weeks ago, and it doesn't exercise the feature at all on FBSD stable trees because of the lack of any interface to doso."
Ответить | Правка | Наверх | Cообщить модератору

43. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+7 +/–
Сообщение от wergus (?), 23-Ноя-23, 13:13
Какой-то наш мир очень однобокий. Когда новость про BTFS с критическими ошибками - "всё нормально! допилят!" А про новость про ZFS - "нууу, всё плохо! сидим на ext(ufs)" При этом, во много благодаря Proxmox, -  тысячи установок, все рады ... но, наверное, они не читают Opennet и чего-то не знают....
Ответить | Правка | Наверх | Cообщить модератору

	82. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (82), 23-Ноя-23, 14:22
	Психология... Они думали что их любят за пятачок и розовый бочок, а оказалось что ойти -- просто мясо и сало для буржуинов. Вот от злости и ходют сюда плеваться на всё подряд, болезные.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (9), 23-Ноя-23, 14:22
	Деды на FAT16 сидели - и вы ДОЛЖНЫ страдать) За родину, за Сталина и вот это вот всё...
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	86. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–4 +/–
	Сообщение от Аноним (86), 23-Ноя-23, 14:26
	Ваш - это какой? Что btrfs, что zfs, нарушающие идеологию юникс ФС, имеющие массу недостатков, часто неочевидных. Их нужно уметь готовить - это уже признак проблемности. Нахваливать такие ФС могут только те, кто продают поддержку, работают на обслуге и т.д.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	142. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
	Сообщение от аНОНИМ (?), 23-Ноя-23, 17:45
	А вы попробуйте реализовать все фичи без нарушения вашей "идеологии". Как минимум с проверкой целостности у вас получится городушка на dm_integrity, которое не сохраняет настройки в своём суперблоке и имеет проблемы с крешами (неоконченная запись данных И чексумм пометит записанные и соседние данные как испорченные), для решения которых, НАДО ЖЕ, там запилено логирование. Поверх этого что там будет, raid5/6? Ну да, с write hole против которого там тоже есть СВОЁ СОБСТВЕННОЕ логирование. Потом наверное будет lvm, уж не знаю насколько там быстры снапшоты и нужно ли там свое собственное логирование. Ну и наконец бесподобный ext4 с ещё одним своим логом. Офигенное ненарушение идеологии вышло, не правда ли?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (165), 23-Ноя-23, 19:31
	> идеологию юникс Вам лишь бы какая, но только бы идеология, чтобы самому думать не надо было. Посмотрел в догмат — и дело с концом! Тьху, поколение инфантилов.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	309. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (309), 25-Ноя-23, 11:29
	По мне так философию Unix выше практичности обычно ставят люди постарше... когда они были помоложе. Борьба с systemd, с flatpak-snap из-за дублирования зависимостей и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (307), 25-Ноя-23, 22:21
	Последователи любой религии смотрят на Вас осуждающе )
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	352. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 23:15
	Раввин смотрит на вас с недоумением...
	Ответить | Правка | Наверх | Cообщить модератору

	300. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 23:22
	> Ваш - это какой? Что btrfs, что zfs, нарушающие идеологию юникс ФС, > имеющие массу недостатков, часто неочевидных. Их нужно уметь готовить - это > уже признак проблемности. Нахваливать такие ФС могут только те, кто продают > поддержку, работают на обслуге и т.д. Да вообще охренеть - оказывается, до того как в кресло КВСа плюхнуться и перевезти 300 человек на другой континент - надо, оказывается, что-то специализированное узнать. Окей, круто, а какие у вас идеи лучше то были? Как вы 300 человек за полдня на другой континент перевезете? А, никак, максимум - пяток, и в другой город? А это немного другой масштаб задач и возможностей был. Такая ерунда. С таким подходом вон там для вас андроид есть, более умные люди решат за вас какие ФС правильно, все такое, можете не париться. А мне вот - знаете куда вы можете с вашей идеологией идти, если у меня система от 1 случайного бэда рассыпается вдрызг? Специальный бонус - если это управляющая система на одноплатнике. Так что нафиг идеологов и позвольте-ка делать как лучше работает по факту, со всеми неидеальностями реального мира. Включая рандомный бэд раз в дофига, или даже что похуже. С чем ваш идеологичный мусор жиденько обделается, вы угрохаете полдня на фикс локалхоста, и это все круто - но только тем что все это не у меня.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	105. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от None (??), 23-Ноя-23, 15:42
	Proxmox - неплохая штука, но как же иногда приходится изворачиваться, чтобы избежать использование ZFS. Так что из этих тысяч установок надо вычитать процент людей, которые уже прошли по граблям.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	106. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+6 +/–
	Сообщение от Аноньимъ (ok), 23-Ноя-23, 15:42
	Потому что брбрфс всегда была кривой и багованной, в здравом уме её использовать не будут, но есть надежда что станет лучше. ZFS же была изначально рабочая и всё с ней было хорошо, пока, разработку не выкинули в зфс он линукс. Поэтому люди которые привыкли к тому что в зфс всё железобетонно и протестуют.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	166. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (165), 23-Ноя-23, 19:37
	> в зфс всё железобетонно Никогда не было. Софт это вообще не про железобетонность, а именно про возможность изменений в любой момент времени под требования текущего момента, и, как следствие, неизбежные ошибки во всём, что сложнее «Hello, world!». Железобетонно — это hardware. Там как напечатали, так и работает. И то заменяемую фирмварь суют, чтобы можно было хотя бы какие-то неизбежные ошибки исправлять. И только диванные с опеннета бухтят, мло раньше-то О-ГО-ГО диды-инженеры с профильным образованием, а сейчас все вокруг хипстеры-смузихлёбы-гуманитарии. Встал бы с дивана и показал как надо, но не покажешь ведь, потому что скиллов нет.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноньимъ (ok), 24-Ноя-23, 02:25
	> Встал бы с дивана и показал как надо, но не покажешь ведь Ломать то что работает как надо - не надо. Вот конкретно на диване сидеть и не ломать - вот так надо.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–2 +/–
	Сообщение от Аноним (208), 24-Ноя-23, 01:13
	> Потому что брбрфс всегда была кривой и багованной, в здравом уме её > использовать не будут, но есть надежда что станет лучше. Вообще-то она уже good enough для монстров размером с FB. У тебя есть прод круче, чтобы вообще иметь наглость умничать? У них - вот - даже базы на 30 терабайтов бывают. А ты такой кейс вообще затестить - как, могешь? > ZFS же была изначально рабочая и всё с ней было хорошо, пока, > разработку не выкинули в зфс он линукс. Поэтому люди которые привыкли > к тому что в зфс всё железобетонно и протестуют. Ну так и пользуйтесь теми ФС и теми ОС, с тем фичесетом. Не хотите?! А вон там 1.1К багов открытых висит. Я посмотрел аж офигел - это я поклацал по ссылкам поха, призадумался что что-то их много и они жестковаты, стало интересно - что за фигня. Я и посмотрел на счетчик открытых багов. И н...я себе сказал я себе! Не, у btrfs'ников столько открытых багов in flight точно нет. Они вообще известные им траблы гасят весьма оперативно. И вы после этого смеете что-то про стабильность рассказывать? А ничего что вон то - никакого сравнения не выдерживает?
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	219. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноньимъ (ok), 24-Ноя-23, 02:22
	> даже базы на 30 терабайтов бывают Так и вижу excited soiboy face. Вау конечно, это целых три диска данных. > иметь наглость умничать > И вы после этого смеете В то время как КПСС в поте лица движется к светлому брбрфс будущему отдельные личности позволяют себе умничать, нацепили дескать очки, книжек начинались, вредители контрреволюционеры. Меж тем третья пятилетка выполнена за неделю, и количество открытых багов ясно показывает преимущества социализма молотом обрушивая капиталистическую очкастую критику партии.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 03:05
	>> даже базы на 30 терабайтов бывают > Так и вижу excited soiboy face. Ну говоря за себя - я так то boy весьма условный, дисков у меня и поболее 3 бывает, а еще я -rc кернела гоняю чартерными рейсами, у меня есть выводки одноплатников, и я все же интересуюсь тематикой "продвинутых фс" и рядом. И кроме всего прочего - я разок не дал btrfs'никам релизнуться с чем-то в духе, хоть и не таким жестким. А таки - в последний момент перед самым релизом загасили кондовый баг. И кстати это было круто и кайфово, я не ожидал такой мощной и компетентной реакции, когда народ просто горой навалился на проблему - и через полдня трабл перестал существовать. > Вау конечно, это целых три диска данных. Может ты там еще и реалистичные ворклоады на базе смогешь? И кстати там никто не знал что база может сломаться, при том - нужно чтобы было 20 терабайт, и никак не менее. Если менее - все ЗБС и баг вообще никогда не вылезает. Ну вот бывают такие баги. Я бы сказал что у сабжа что-то такое же вышло, но - там экзотичные файлы не требовались, а 1.1К багов в трекере и довольно колоритные экспонаты наводят меня на мысль что проблема, кажется, имеет более систематический характер и гражданин пох кроет их все же не просто так. Не, у других такой же помойки в багтрекере я вообще не видел. Особенно с таким числом открытых багов. > В то время как КПСС в поте лица движется к светлому брбрфс > будущему отдельные личности позволяют себе умничать, нацепили дескать очки, > книжек начинались, вредители контрреволюционеры. На КПСС тут скорее ZFSники похожи. Много сказок про светлое будущее, поливание помоями проклятых капиталистов^W бтрфсников, а на практике - жоский багодром, багтрекер аналогов которому для других ФС я тупо не знаю (у кого еще 1.1К незакрытых багов?) и вообще - на поверку оказывается что болты закручивали, походу, кувалдой. > Меж тем третья пятилетка выполнена за неделю, и количество открытых багов ясно показывает > преимущества социализма молотом обрушивая капиталистическую очкастую критику партии. Преимущества мной проверяются на своей тушке. Сабжа я конечно не запускаю - у меня уже на половине систем ядра 6.6 используются, а в багтреке там с тем что новее 6.1 капец просто творится. Тем временем я прям ща пуляю тесты 6.7-rc чартерными рейсами. И мне нормуль. И там кроме вундервафли кента, так то, и btrfs'никам ништяков завезли, просто этот сейчас купается в лучах славы, и вообще, он это заслужил 10 годами упорного вджоба к свеой цели. Теперь он гордый суслик, который может сказать "I did it" - предъявить конкретное достижение. И мне не важно как это называется. Мы пашем вокруг линуха чтобы видеть именно такие моменты. Это доставляет.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 18:10
	> Какой-то наш мир очень однобокий. > Когда новость про BTFS с критическими ошибками - "всё нормально! допилят!" > А про новость про ZFS - "нууу, всё плохо! сидим на ext(ufs)" > При этом, во много благодаря Proxmox, -  тысячи установок, все рады > ... но, наверное, они не читают Opennet и чего-то не знают.... Да ты не бойся, восстановление пула из бэкапа сллжно будет не заметить :)
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	291. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 21:38
	> Какой-то наш мир очень однобокий. > Когда новость про BTFS с критическими ошибками - "всё нормально! допилят!" > А про новость про ZFS - "нууу, всё плохо! сидим на ext(ufs)" Разработчики btrfs в курсе что фичи надо до релиза тестить. И тестов у них есть. И ума запускать XFS test suite чартерными рейсами, побольше XFSников - хватает. А еще им проще - в майнлайн интегрированы, поэтому они знают про все импактящие их изменения. А вон те узнают про некоторые изменения путем размазывания атомов тестовых хотя, судя по сабжу, не только тестовых уже. Так конечно тоже можно. Вон там в багтреке радостные вопли "в количестве". > При этом, во много благодаря Proxmox, -  тысячи установок, все рады > ... но, наверное, они не читают Opennet и чего-то не знают.... Судя по тому что фороникс тоже отметился - таки, видимо, волшебный пинок под зад достался не только опеннетчикам. Разлет от релиза фичи без тестирования получился хорош. А чего ожидалось то от потуг релизнуть фичу без ее нормального тестирования? Ну и затестили в продакшне.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

46. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
Сообщение от Аноним (46), 23-Ноя-23, 13:21
>ошибка, которая может привести к повреждению файлов Да несколько лет назад в течение довольно длительного времени в реализации ext4 в ядре Linux была ошибка, приводящая к повреждению фс, включая повреждение файлов, как системных, так и в home. В качестве вокрараунда я ставил полную проверку ФС на каждый перезапуск через добавление файла в корень через systemd unit и перезагружался почаще (каждая перезагрузка занимала долгое время). Если не перезагружаться почаще - можно было возможно вылететь, и после - загрузиться в initrd и полсистемы через пакетный менеджер переустанавливать. Я ещё подозревал аппаратные проблемы с жёстким диском, но диск был хитачи и имел хорошие SMARTы. Хорошо что купить новый диск я не мог, это были бы потраченные на ветер деньги.
Ответить | Правка | Наверх | Cообщить модератору

	55. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (153), 23-Ноя-23, 13:49
	Похоже, только там были не нули в файле, а сам файл тупо обрезался до нулевой длины. Если я о том же баге вспомнил. Их тоже было не мало.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:08
	Если не работает write barrier - это и сейчас может происходить.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	70. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 14:14
	> Если не работает write barrier - это и сейчас может происходить. write barrier ни от каких повреждений файлов не спасает. Он спасает от автоотката на состояние фс до сотворения мира при крэше. А silent data corruption (опять неумельцы пользуются поиском по сайту или идут найух) - он всегда с тобой.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:20
	Почитай повыше - о чём речь. Речь об обрезке метаданных. В основном сие случается, когда кусок журнала с новыми метаданными потерян. А если нет write barrier - ты хоть как ужом вертись. Ну и да, silent data corruption - это вот то самое, чем ZFS в описанном в новости случае и занимается.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 24-Ноя-23, 11:23
	> В основном сие случается, когда кусок журнала с новыми метаданными потерян. А если нет write > barrier - ты хоть как ужом вертись. write barrier всего лишь делает этот кусок ограниченным во времени (ценой потери производительности) ничего не меняя по сути. > Ну и да, silent data corruption - это вот то самое, чем ZFS в описанном в новости случае и > занимается. вроде бы нет - там портятся копируемые файлы, а не как у ext4, вообще лежавшие на диске и не трогаемые сто лет. Но это неточно и я бы подождал пока хоть как-то устаканятся мнения. А то может оказаться что запрет рефлинков и тем более запрет непонятной клариной херни - не совсем то что помогает.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 21:52
	> write barrier всего лишь делает этот кусок ограниченным во времени (ценой потери > производительности) Не ограниченная сверху потеря данных - черт, звучит многообещающе. Зато какой слог, какой стиль. Так даже разлет пула вдрызг - нормуль, вас предупредили же. > ничего не меняя по сути. Проблема в том что все файлухи таки уповают на определенную семантику и ее работу. Если вдруг это не так - оно может и будет работать в тепличных условиях, но вот гарантий что там случится, особенно при отклонениях от идеала - примерно ноль. Потому что выходит за допущения дизайна и ты проверяешь своей тушкой что означает "undefined" и как это будет. В принципе обычно то везет, а если избыточность есть, издевательства над теорвером могут и довольно долго сходить с рук. Но все же лучше иметь какой-то план на случай если удача все же закончится. > вроде бы нет - там портятся копируемые файлы, а не как у > ext4, вообще лежавшие на диске и не трогаемые сто лет. Ну как бы да. Однако тут тоже "копии" без анонса получаются левые какие-то. А фича пошла в массы и вон те уже и по дефолту это стали. Ах, представляете какие наглецы, еще и пользуются фичами. Подразумевая что они еще и работать должны! > Но это неточно и я бы подождал пока хоть как-то устаканятся мнения. > А то может оказаться что запрет рефлинков и тем более запрет > непонятной клариной херни - не совсем то что помогает. Какие корралы на этот раз Клара украла у Карла?
	Ответить | Правка | Наверх | Cообщить модератору

	210. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 01:33
	>> Если не работает write barrier - это и сейчас может происходить. > write barrier ни от каких повреждений файлов не спасает. Он спасает от > автоотката на состояние фс до сотворения мира при крэше. Немного не так. Если у тебя это не работает в железе - откат вообще сработать не обязан и то что после его потуг у тебя будет технически-корректное, логически консистентное состояние ФС, где данные и метаданные описывают одно и то же - вообще ниоткуда не следует. Какие-то взбрыки такого плана может парировать избыточность и чексумирование, но вообще это испытание своей удачи. Довольно хреновым и чреватым способом. Потому что это выходит за допущения дизайна ФС. > А silent data corruption (опять неумельцы пользуются поиском по сайту или идут > найух) - он всегда с тобой. С чексумами и избыточностью то - его как раз можно нехило замахать. В чем пойнт этой академической гребли и состоит.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	239. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:56
	> Немного не так. Если у тебя это не работает в железе - Ну и я о том же. Write barrier должен работать от ведра до конечного диска.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 23:40
	>> Немного не так. Если у тебя это не работает в железе - > Ну и я о том же. Write barrier должен работать от ведра > до конечного диска. Ну как бы это сказать? В идеале, фс, особенно с избыточностью, должна бы переживать и lost write/reordered write/труху в тех или иных секторах и прочие странные загоны накопителей. Другое дело что вылезти за допущения дизайна все же можно, да и стресстестить логику selfheal лишний раз - ну в общем то не очень умная идея. Даже если обычно и прокатывает. И каких-то реально эффективных гарантий почему все это ОБЯЗАНО сработать, с произвольными факапами железа - ну, вот, нет при нарушении той семантики. Просто потому что то что файлуха пыталась и то что по факту получилось может оказаться двумя довольно большими разницами, и насколько это втиснется в допущения дизайна - вопрос интересный. Но я вот юзанул BTRFS с схемой DUP в ряде мест - и очень радикально пересмотрел теорвер, теперь я проигрываю не "если 1 бэд вынес критичные структуры" а "если два бэда накрыли две копии блока". А это вообще совсем другое допущение, и вот так мне теорвер и игра в ту рулетку нравится намного больше. Почему-то. Да, это не 100% решение. Но на практике так намного лучше работает. А Вы можете переставлять операционку после того как libc6 не прочитался, я совершенно не против, если такой булшит бинго будет у вас.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 25-Ноя-23, 10:07
	> А Вы можете переставлять операционку после того как libc6 не прочитался, > я совершенно не против, если такой булшит бинго будет у вас. Я за 15 лет на всей инфре ни один раз в бэкап не залез по причине повреждения данных, такие дела... Но бэкапы делаются исправно. Потому что есть прочие задачи - например найти, когда юзер себе что-то снёс и плачет.
	Ответить | Правка | Наверх | Cообщить модератору

	320. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 25-Ноя-23, 23:53
	> Я за 15 лет на всей инфре ни один раз в бэкап > не залез по причине повреждения данных, такие дела... Это может свидетельствовать о самых разных вещах, как минимум... 1) Удачливый тип. 2) Админ локалхоста с полутора тазиками и статистикой под стать. 3) Информация была не очень то и нужная, никто и не парился. 4) Если вам кажется что дела идут хорошо, возможно вы просто чего-то не заметили. С какимнить EXT4 - легко. Ему все пофиг, включая и целостность данных. 5) Тепличные условия, типа упсов, не очень активных операций, идеального железа, пофигистичных юзерей, ... . А также много чем еще. Если вы хотели сказать что к тому были какие-то логические предпосылки и ваши заслуги - это неплохо бы обосновать. С учетом любви к примитивным ФС мне кажется что это ближе всего к пункту 4) может оказаться. А как вы вообще глобально проверяете живость всех данных? А, никак? Это хитрый план. Нет integrity check, нет факапов с ним, кто б спорил. Но мне кажется что в логике страуса с закапыванием бошки в песок есть какая-то подстава. > Но бэкапы делаются исправно. Потому что есть прочие задачи - например найти, > когда юзер себе что-то снёс и плачет. Ну дык. А я вот как-то скатался из-за 1 сраного бэда раз в дофига лет вылезшего под либц6 в знатные перди в авральном режиме. Не понравилось! Я и пересмотрел подход к созданию систем, когда соотношения сильно иные и куда больше в мою пользу. В том числе и по линии теорвера. Который таки не пустой звук - особенно по мере роста емкостей, скоростей, да еще подпертого желанием вон тех - чтоб это все еще и за копейки. В этом месте идея гонять на антикварной файлухе без self repair и чексум начинает выглядеть для меня не очень хорошим планом, ибо тест следствий законов Мерфи из пункта 4) прямо на себе - не кажется мне отличной идеей.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 01:29
	> Да несколько лет назад в течение довольно длительного времени в реализации ext4 > в ядре Linux была ошибка, приводящая к повреждению фс, включая повреждение > файлов, как системных, так и в home. В качестве вокрараунда я > ставил полную проверку ФС на каждый перезапуск через добавление файла в > корень через systemd unit и перезагружался почаще (каждая перезагрузка занимала долгое > время). Если не перезагружаться почаще - можно было возможно вылететь, и > после - загрузиться в initrd и полсистемы через пакетный менеджер переустанавливать. > Я ещё подозревал аппаратные проблемы с жёстким диском, но диск был > хитачи и имел хорошие SMARTы. Хорошо что купить новый диск я > не мог, это были бы потраченные на ветер деньги. ...а чтобы не заниматься всей вот этой НЕВМЕНЯЕМОЙ ХРЕНЬЮ вместо эксплуатации систем я и юзаю btrfs ;). Там если железо сбоит - вопли "csum error" сразу покажут что хардвар дурит. Даже если винч исправный, это не доказывает что проц, чипсет и память ведут себя как надо. И какая разница кто из них битик вон там крутанет или неправильно посчитает. В результате можно получить факап и очень плохо если это - ВНЕЗАПНО. Гадать корректно ли работает железо это булшит, end to end проверки с чексумами - EPIC WIN, и по этой фиче я полностью согласен с ZFS'никами. А делать перезагрузки и fsck - извините, но это прерывает доступность сервиса а на современных размерах томов fsck еще и совсем не быстрая операция. Это компы для людей - или мы еще будем тут изгибаться в три погибели под какие-то дурацкие техниеские особенности? А оно в таком виде - точно надо? Про то что онлайн проверка и вообще-то scrub, а желательно с self heal из избыточной копии, если она есть - это хорошо и правильно - даже и упоминать неудобно. Автралопитеки с EXT4 с бамбуковым самолетом вообще не понимают прелестей бортового компьютера (из бамбука он фигово эмулируется, увы). В этом аспекте я таки понимаю ZFSников. А subj - ну, они что-то нагнули в процессе разработке и таки какие-то проблемы с "общим качеством кода" кажется пошли.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

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

	289. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (289), 24-Ноя-23, 20:09
	> Та же проблема: как только у тебя факапнется метадата в силу программной > ошибки - больше ты оттуда вообще ничего не выгребешь. 1) Вообще, сэр, я Data Recovery на полупро уровне с уклоном в линух занимаюсь малость, себе по кайфу. Поэтому "I know what I'm doing". 2) Мне тут это уже лет 10 чтоли обещают. А оно все никак, так что для других только вот рекавери делаю. 3) Лучший Data Recovery - который не потребовался. А именно - Сбои как правило ведут к "csum error" ДО того как это станет более крутой проблемой. - На схемах с избыточностью зачастую оно могет в self repair. - Оперативное устранение факапов железа очень способствует вон тому. - С качеством софта и интеграцией в майнлайн у них имхо сильно лучше вон того позора, имхо. 4) Если вдруг - ну я более представляю себе структуру этой штуки, знаю рекавери опции, знаю где живет офлайн парсер (для EXT4 такая прелесть вообше доступна только в коммерческих виндовых прогах, на минутку) - а поскольку это cow, есть сильно более 1 точи входа. И можно попытаться довольно много чего ДО того как всякими testdisk и photorec колупаться. 5) Если вдруг вон того окажется мало - я таки знаю где и как спросить "помощь зала". И да, я вполне в состоянии флипнуть битик в хексэдиторе и чего там еще, мануально вправив метаданным мозг за глючным железом. Если вдруг так надо. > На экстах хотя бы просто сканированием можно кое-что вытащить, файлы мешаниной по диску > не размазаны. Угу. А при полном отказе накопителя вы вытаскиваете - например, что? А на RAID1 и с таким жить можно. Да что там, с DUP на сыпучей флехе btrfs - вот - изумительно крутит теорвер в мою пользу. А EXT4 там в труху за месяц - легко! При том без чексум не то что self repair нет, но и диагностики, просто в какой-то момент он умрет, без предупреждений. В общем совсем другой уровень технологий. Со знаком минус. За отсутствие диагностики и ранних предупреждений.
	Ответить | Правка | Наверх | Cообщить модератору

	293. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 24-Ноя-23, 21:59
	С перфокарт рекаверишь?
	Ответить | Правка | Наверх | Cообщить модератору

47. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от лютый арчешкольник... (?), 23-Ноя-23, 13:26
ZFS и без этого бага мусорок... Кто её хвалит, снэпшотами то пробовали пользоваться хотя бы годик? Скорость падает ниже плинтусни...
Ответить | Правка | Наверх | Cообщить модератору

	218. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 02:14
	> ZFS и без этого бага мусорок... Кто её хвалит, снэпшотами то пробовали > пользоваться хотя бы годик? Скорость падает ниже плинтусни... Ну как бы в CoW размер дельты надо все же контролировать, чудес не бывает. Иначе оно таки зафрагментится и места жрать - будет. Другое дело что в ZFS на этот случай вообще совсем никакого плана нет. Дефрага нема.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от нах. (?), 24-Ноя-23, 11:26
	ты перепутал со своим любимым lvm. У CoW никакой дельты нет. Новые записи ВСЕГДА "дельта". Разница только в том что если старые зафиксированы в снапшоте - они не будут со временем перезаписаны чем-то другим. У меня снапшоты никак не влияют на скорость фс. Местный дypaчок скорее всего в очередной раз забил фс выше 90% но виноваты конечно снапшоты.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 22:26
	> ты перепутал со своим любимым lvm. Я как раз терпеть его не могу, считая отвратительным легаси. CoW файлухи это эстетичнее делают, сделав все нужные метаданные нативной частью дизайна. Так сильно лучше работает чем те убогие костыли. Конечно если сильно хочется, можно и запорожец, на орбиту, но... > У CoW никакой дельты нет. Новые записи ВСЕГДА "дельта". Спасибо, Капитан Очевидность! Это не отменяет того факта что де факто есть "core set" блоков на которые N референсов, и эн "дельт" которые разъехались относительно оного и были записаны cow в сторонку. Может и сложнее быть, упрощенная картинка позволяет чайникам понять суть проблематики и особенности управления таким звездолетом. CoW диски виртуалок по примерно таким же идеям работают и сталкиваются с похожими проблемами. Хотя они будучи блочными сущностями скорее ближе к LVM, но общая идея остается. Просто для продвинутого cow оно становится сложнее и многофакторнее. Можно такие вот ансамбли миров отращивать, с разными таймлайнами. Совпадающие часты могут (но не обязаны) храниться вместе. Отличающиеся по отдельности. > Разница только в том что если старые зафиксированы в снапшоте - они > не будут со временем перезаписаны чем-то другим. Вот ты кэп то! :). Прости, я в курсе как устроен гипердрайв и как им продвинуто рулить. > У меня снапшоты никак не влияют на скорость фс. Они сами по себе - в разумных пределах - и не обязаны. А с чего им? Сам по себе лишний референс на энный экстент вообще жить никак не мешает. В zfs наверное чуть больше оверхеда с их блоками переменного размера, но оно бы не было cow если бы не могло с этим жить. А вот если не понимать те аспекты управления такими гипердрайвами - можно забить себе пространство и налететь на фрагментацию. В вобщем то любом дизайне. Даже дисками виртуалок так можно доиграться. Факт в том что должен быть некий маневровый резерв кужа cow'ать можно. > Местный дypaчок скорее всего в очередной раз забил фс выше 90% но виноваты конечно > снапшоты. Ну как, если протупить с управлением снапшотами, место как раз "куда-то" и профакается. А если кто загнал аллокатор в субоптимальный режим, когда тот какие-то крохи по всем закоулкам выскребал - ну окей, и что они хотели в результате получить, кроме дикой фрагментации? Btrfs'ники то на этот случай могут потрепыхаться дефрагером. Хоть и с "особенностями".
	Ответить | Правка | Наверх | Cообщить модератору

48. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от Аноним (153), 23-Ноя-23, 13:36
Кто накосячил? Опять Клара или чудные линукс-смузихлёбы? Пока линуксоиды не начали программировать свой ZOL, всё было относительно неплохо. Давно ждал такой диверсии. Что вы не орёте теперь, что ZFS для FreeBSD разрабатывают линуксоиды.
Ответить | Правка | Наверх | Cообщить модератору

	72. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 14:15
	А чё орать-то? Сидим на 12-й ветке FreeBSD, в которой православная ZFS, а не САБОТАЖ, и смотрим на обмазующихся свеженьким линуксом с некоторым недоумением, хотя пора бы уже и привыкнуть.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (153), 23-Ноя-23, 18:02
	Так обычно про разработку zfs для freebsd линуксоидами орут сами линуксоиды. Они на 12-й ветке не сидят. А сейчас тихо, потому как баг. И неизвестно, вдруг линуксоиды накосячили, значит орать нельзя. Вот выяснится, что это бсдэшники всё поломали, тогда начнут орать и про бсд, и про не сумевших дидов, и про ненужность.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Лёха (?), 24-Ноя-23, 14:47
	В 15 вроде тоже норм, жрать не просит, падать не валится, хоть и не труЪ православная... (оговорюсь -- на десктопе).
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	77. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 14:19
	> Кто накосячил? Опять Клара или чудные линукс-смузихлёбы? похоже не клара - клара случайно вляпалась. С девушками это бывает. Т.е. вытащили на поверхность какой-то кал вероятно бывший там давно, но из-за четного числа ошибок не проявлявшийся. > Пока линуксоиды не начали программировать свой ZOL, всё было относительно неплохо. Давно э... там в том самом чудо-тредике передавали привет hole_birth Как ни странно, пока линуксоиды не начали - число багов было четным и оно не проявлялось. Баг, заметим, именно линуксоиды потом и исправляли. > ждал такой диверсии. там совсем другие диверсии. Но для этого надо владеть темой, а это не для экспертов опеннета.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	88. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (153), 23-Ноя-23, 14:27
	> вытащили на поверхность какой-то кал вероятно бывший там давно Ууу, так это санки виноваты, что в линуксе проявилось? Ах они, негодники! Всё заранее продумали. :D > пока линуксоиды не начали - число багов было четным и оно не проявлялось Вот именно, что не проявлялось. Пока кто-то не начал расшатывать. Но вопрос пока остаётся открытым. С таким раскладом фряхе остаётся только заменить все подсистемы ядра на линуксовые и сидеть бить баклуши. Что и происходит. Отличная работа, FreeBSD Foundation!
	Ответить | Правка | Наверх | Cообщить модератору

	98. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 14:56
	> Ууу, так это санки виноваты не помню кто там автор - возможно уже наследники из иллюмоса. Да, разумеется - это их баг. Не проявлялся потому что этим куском кода никогда не пользовались вообще, он был на новый год. Найдено и исправлено - линуксной тусовкой. Когда-то она такое - могла. > Отличная работа, FreeBSD Foundation! foundation не может ничего противопоставить дерьмоделам из iX.
	Ответить | Правка | Наверх | Cообщить модератору

49. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
Сообщение от fidoman (ok), 23-Ноя-23, 13:37
Всё, доломали легаси?
Ответить | Правка | Наверх | Cообщить модератору

	100. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 15:22
	в том и дело что понять не могут. Если только легаси - выключаешь фичу и спишь спокойно. Но нет уверенности что это наоборот, не привет от бага из дремучего легаси, до которого случайно докопались вот сейчас.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 23-Ноя-23, 21:58
	> в том и дело что понять не могут. Если только легаси - > выключаешь фичу и спишь спокойно. > Но нет уверенности что это наоборот, не привет от бага из дремучего > легаси, до которого случайно докопались вот сейчас. Судя по https://github.com/openzfs/zfs/issues/15275 - покой вам только снится. Там если вокруг по ссылкам поклацать, можно надолго потерять спокойный сон. Такого даже у Кента хрен найдешь, пожалуй.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 16:17
	> Всё, доломали легаси? И что теперь на хайпе, если ZFS стал легаси? Файл система БТР?
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

51. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от fidoman (ok), 23-Ноя-23, 13:39
Интересно, этим "разработчикам" не приходила в их светлые головы мысль, что если я копирую файл, то мне нужна КОПИЯ файла, а если я хочу чтобы эти два файла ссылались на одни и те же блоки, то я бы включил -o dedup?
Ответить | Правка | Наверх | Cообщить модератору

	134. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от 1 (??), 23-Ноя-23, 17:12
	Ну и чем КОПИЯ (авторская раскладка сохранена) отличается от копии с автодупликацией ? Тебе на пользовательском уровне не всё равно Если тебе нужна прям КОПИЯ КОПИЯ - копируй в другое облачко.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (165), 23-Ноя-23, 19:43
	> Ну и чем КОПИЯ (авторская раскладка сохранена) отличается от копии с автодупликацией ? Тем, что при повреждении носителя вероятность потерять все копии значительно ниже. > Тебе на пользовательском уровне не всё равно У пользователей Винда и Мак, на которых ZFS, очевидно, нет. При чём тут пользовательский уровень к серверным файловым системам? > Если тебе нужна прям КОПИЯ КОПИЯ - копируй в другое облачко. Я и есть «облачко». Что теперь делать прикажешь?
	Ответить | Правка | Наверх | Cообщить модератору

	172. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (172), 23-Ноя-23, 20:11
	>У пользователей Винда и Мак Где Вы берёте таких пользователей? На более разумных не хватает ФОТ?
	Ответить | Правка | Наверх | Cообщить модератору

	203. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (165), 24-Ноя-23, 01:01
	У 1% элитарных войнов-линуксойдов денег нет. Приходится с быдло99% возиться. А что сделать, элитность юзеров в тарелку не положишь.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от fidoman (ok), 23-Ноя-23, 20:06
	1) меньше i/o, потому что при записи не надо аллочить блоки и обновлять счётчики ссылок. 2) уверенность, что при перезаписи этого файла (если это образ виртуалки к примеру) неожиданно не кончится место - то есть информация о том что места не хватает вылезет в момент когда человек сидит за консолью и копирует, а не в 23:00 31.12 Ах да, простите, наверное я всё же не ответил на ваш вопрос. С ПОЛЬЗОВАТЕЛЬСКОЙ точки зрения, конечно же, всё равно.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	235. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от 1 (??), 24-Ноя-23, 09:47
	> 1) меньше i/o, потому что при записи не надо аллочить блоки и обновлять счётчики ссылок. Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? Я что-то пропустил и завезли новую математику ? > 2) уверенность, что при перезаписи этого файла (если это образ виртуалки к примеру) неожиданно не кончится место Это вот ближе к теме ... Правда не при "перезаписи", а при перемещении ... на другой датастор, например. Всегда есть вероятность, что при дедупликации и сжатии места не хватит при реаллокейте ... Но что-то я мало видел желающих проводить работы в 23:00 30.12. Тут же отвечу из поста повыше, по поводу порчи места на носителе... Там между носителем и FS ещё пара уровней имеется.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от fidoman (ok), 24-Ноя-23, 12:50
	> Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? Я что-то пропустил и завезли новую математику ? Не завезли, но есть такая вещь как планирование. Копирование запускаем в период наименьшей нагрузки, затем в пиковых режимах избыточной нагрузки уже не будет. Собственно удобно было бы если бы оно после предоставления копии с рефами уже в фоне разносило бы блоки, но этого вроде как нет. Даже если сделать сложную схему с преаллоком, что читаем из тех блоков, а новое пишем вот сюда - всё равно дополнительные расходы на то чтоб отметить, что блок из оригинала уже не нужен (уменьшить рефкаунт) и отметить что читать уже из нового (дополнительная запись в метадату).
	Ответить | Правка | Наверх | Cообщить модератору

	326. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 26-Ноя-23, 01:35
	>> Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? >> Я что-то пропустил и завезли новую математику ? > Не завезли, но есть такая вещь как планирование. Копирование запускаем в период > наименьшей нагрузки, затем в пиковых режимах избыточной нагрузки уже не будет. Ну во первых оно займет место. И это стоит денег. Во вторых - IO таки грузит. И долго. Если результат этой операции интересовал (а иначе она зачем вообще?) - все надолго встает на якорь. > Собственно удобно было бы если бы оно после предоставления копии с > рефами уже в фоне разносило бы блоки, CoW так и работает по задумке - как блоки расходятся, так оно и. А если не расходятся - зачем на них место и IO тратить? > но этого вроде как нет. Даже если сделать сложную схему с преаллоком, что читаем из > тех блоков, а новое пишем вот сюда - всё равно дополнительные расходы на то чтоб отметить, Показать метаданными 2 раза на 1 регион само по себе вообще не обязано быть чем-то тяжелым. > что блок из оригинала уже не нужен (уменьшить рефкаунт) и отметить что читать > уже из нового (дополнительная запись в метадату). Какой-то оверхед по метаданным конечно добавится, но по сравнению с явным копированием вон того терабайта это будут сущие мелочи...
	Ответить | Правка | Наверх | Cообщить модератору

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

	231. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от fidoman (ok), 24-Ноя-23, 09:19
	> явно запросил Откуда инфа про "явно"? В обсуждении пишут что оно автоматом стало делаться при копировании в свежих coreutils. > Что актуально для деплоя десятка виртуалок из шаблона например сделай zfs clone шаблона и запускай Не так гибко в том плане что нельзя шаблон грохнуть, но по крайней фича старая и больше шансов, что работает нормально, и не включается сама там где её не просят.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 24-Ноя-23, 19:32
	> Откуда инфа про "явно"? В обсуждении пишут что оно автоматом стало делаться при копировании в > свежих coreutils. кому интересны ваши гнупроблемы? Предъявляйте претензии авторам корявоутилсов, зачем они делают у вас то о чем их никто не просил. > сделай zfs clone шаблона и запускай Как жаль что zfs не умеет clone отдельных файлов (нет) Песок плохая замена овсу. Отсутствие у cow-based fs рефлинков - очень странная проблема. Как бы намекающая нам что в разработке все плохо (потому что попытки ее решить тянутся уже лет пять)
	Ответить | Правка | Наверх | Cообщить модератору

	290. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 24-Ноя-23, 20:19
	>> явно запросил > Откуда инфа про "явно"? С точки зрения файлухи - софт должен явно ioctl вхреначить на это дело, сигняля что они хотят вот именно клон файла. > В обсуждении пишут что оно автоматом стало делаться > при копировании в свежих coreutils. Возможно. Это в конечном итоге вопрос дефолтов энных программ. Лично мне например такие дефолты удобны - если я хочу копию файла как именно нечто занимающее +эн места, я это обычно на ДРУГОЙ ФС хочу. Как раз из соображений сохранности. Потому что rm -rf или dd в накопитель например убьет обе копии одинаково эффективно. И занимать 2 раза на 1 ФС/накопителе место - ну - знаете, если это реально надо было - то RAID1 и DUP это делают лучше. Еще и с чексумами. Можно сразу понимать кто побился, чинить это в фоне, и без педального привода чтобы закатывать солнце вручную. >> Что актуально для деплоя десятка виртуалок из шаблона например > сделай zfs clone шаблона и запускай > Не так гибко в том плане что нельзя шаблон грохнуть, но по > крайней фича старая и больше шансов, что работает нормально, и не > включается сама там где её не просят. Да у меня btrfs так то, а ща я начинаю немного экспериментировать с кентовским bcachefs. Судя по вашему багтреку я не ошибся с идеями как работает интеграция с майнлайном внешних модулей. Там для свежих ядер вообще капец, толпа господ с багами на которые всем похрен. Но если кому ваш совет пригодится - я рад за них.
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	308. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от fidoman (ok), 25-Ноя-23, 11:19
	> из соображений сохранности Не о сохранности речь, если бы речь была о ней, то, допустим, сделать копию файлика в папочку save перед тем как вносить какие-то изменения - тут reflink был бы как раз уместен, эдакий снепшот 1 файла, разрастающийся только по мере того, как делается cow. Нет, вопрос если я делаю копию допустим файла БД или образа диска и хочу чтобы это была другая БД/виртуалка - тут уже однозначно надо, чтобы все блоки были сразу закопированы и у каждого файла они были свои - и дальнейшая работа с ними происходила без дрoчилова метадаты.
	Ответить | Правка | Наверх | Cообщить модератору

	322. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 26-Ноя-23, 00:52
	>> из соображений сохранности > Не о сохранности речь, если бы речь была о ней, Если это не интересовало, то идея делать вот именно полную честную копию, когда возможно рефлинк - довольно странная. Это сожрет больше места, потратит больше времени, а профит - в чем? > то, допустим, сделать копию файлика в папочку save перед тем как вносить какие-то > изменения - тут reflink был бы как раз уместен, эдакий снепшот > 1 файла, разрастающийся только по мере того, как делается cow. Ну да. И на уровень менеджмента ЭТО как раз и не отсвечивает, будучи 100% прозрачной абстракцией для решения вот именно вопроса создания локальных независимых якобы-копий. Которые можно, вот, независимо эволюционировать и проч. Например так удобно поднимать пачку однотипных виртуалок для какого-то эксперимента из шаблона. Если известно что виртуалки будут не особо активные по записям, и в целом похожие, но мелкие отличия типа легкой кастомизации конфигурации - вот - совершенно прозрачно прокатят, хотя "core set" блоков в лучшем случае останется один на всю толпу, а десяток экземпляров нарезается из шаблона без натужного копирования дофига гигз. При этом мы врядли хотели чтобы сам факт создания такой штуки - как-то отсвечивал в менеджменте именно ФС. Какие-то ключевые моменты - при определенных условиях - еще может быть. Но за сам факт создания такой штуки? Ну вот нет. > Нет, вопрос если я делаю копию допустим файла БД или образа диска > и хочу чтобы это была другая БД/виртуалка - тут уже однозначно > надо, чтобы все блоки были сразу закопированы и у каждого файла > они были свои - и дальнейшая работа с ними происходила без Да? А я то делая дата рекавери как раз оценил что вычитав вооон ту немеряную чушку с эн-терабайтного подубитого диска, можно на ней экспериментировать, например, не догонит ли fsck это до моунтабельного вида, сделав как раз рефлинкнутую копию. И как раз та иллюзия с одной стороны делает "копирование" моментальным (копировать несколько терабайт в принципе очень не прикольно) - и экономит дофигища места. А прозрачная абстракция поддерживает иллюзию что это разные файлы. И вот fsck лихо чинит "копию" диска-в-файле. Большая часть блоков конечно же shared останется, а в сторонку запишутся только изменения от fsck. А дальше - если не понравился результат, стер этого рефлинка да еще раз попробовал! А оригинал - вот, как раз, лежит себе, его никто не трогает. И в целом так соотношения намного круче. И по нужде в месте на стораже куда это складируется, и по времени на то чтобы переиграть вариант результат которого не понравился. Есть большая разница между копированием нескольких терабайтов и рефлинком на них. Второе завершается за какие-то секунды. Если это было про диски виртуалок и проч - вот там уже смотреть надо. Для малоактивных виртуалок, таки, рефлинк может быть вариантом. Для активных по дисковому IO - ну вот там вы CoW врядли хотели уже. А таки пачка виртуалок таким манером лихо подымается, и как вариант в палитру - очень даже. Но вот там уже стоит понимать что и зачем делаем.
	Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

60. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:02
Как ЖЫ ТАК. А вот эта вся сквозная целостность феерическая? Чексуммы на каждый чих, вдруг битик улетит (с диска-то, у которого свой ECC, и по шине с контролем чётности?)... А вот так. Как и говорил - вся эта мифология разбилась о повреждении данных до каких-либо проверок и сумм.
Ответить | Правка | Наверх | Cообщить модератору

	249. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от нах. (?), 24-Ноя-23, 11:31
	ну не торопись - мы же можем еще и наоборот - неправильно посчитать сумму правильных данных. И ХРЕН мы теперь тебе дадим их прочитать!
	Ответить | Правка | Наверх | Cообщить модератору

69. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–2 +/–
Сообщение от Аноним (69), 23-Ноя-23, 14:12
ext4 - самая стабильная и надежная если хранить файлы xfs - кончается место - данные xfs_repair убивает zfs - просто рассыпается из-за неудачного ребута сервера btrfs - ничего сказать не могу, особо не юзал, но говорят данные теряет как xfs и zfs вместе взятые причем полностью и починке не подлежит есть еще ufs2 у фряшников, так то вообще не фс, а какое-то недоразумение
Ответить | Правка | Наверх | Cообщить модератору

	76. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–3 +/–
	Сообщение от Аноним (82), 23-Ноя-23, 14:18
	> ext4 - самая стабильная и надежная если хранить файлы > xfs - кончается место - данные xfs_repair убивает > zfs - просто рассыпается из-за неудачного ребута сервера > btrfs - ничего сказать не могу, особо не юзал, но говорят данные > теряет как xfs и zfs вместе взятые причем полностью и починке > не подлежит > есть еще ufs2 у фряшников, так то вообще не фс, а какое-то > недоразумение С ext4 без трёх бекапных копий вообще работать невозможно. Да ещё и 12309 донимает.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Аноним (153), 23-Ноя-23, 14:20
	Но ты ufs2 в глаза не видел, особо сказать ничего не можешь, но всё же говоришь. Конечно фс со снапшотами против ext4 без них - недоразумение, куда ей до этого. И почитай историю ext-систем. Узнаешь, где ФС, а где нет. :)
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	118. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от fidoman (ok), 23-Ноя-23, 16:08
	> zfs - просто рассыпается из-за неудачного ребута сервера ZFS убить ппц как сложно, видел только при откровенно дохлом БП, когда диски на ходу отщёлкивались. Убивалась до состояния что вытащить файлы можно было только дебагом. А так если скрабить регулярно нихрена ей не будет. На компах собранных вот буквально из г. и палок работает нормально. Условия только два - качественные шлейфы и диски с чистым смарт.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

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

	389. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (-), 28-Ноя-23, 19:11
	> Вот в этой новости - оно самоубивается. До состояния "не вытащить никак". > Ну, то, что убилось, конечно. С практической точки хрения, если у вас даже и убилась копия копии файла - это, конечно, ужас. Особенно для такой ФС. Но все же не ужас-ужас. Хотя-бы потому что не битые копии должны бы все же остаться, а вероятность наступить на этот баг - достаточно умеренная. Но вот фану EXT4 на это жаловаться?! А вы как, используете EXT4 с полным журналом и наслаждаетесь тупняками записи минимум ВДВОЕ? Или - забиваете на тот факт что при крахе БЕЗ полного журнала файло может оказаться наполовину старым и наполовину новым? Просто потому что при журнале только метаданных нет инфо ни довести транзакцию до конца, ни чтобы откатить, поэтому вот вам полуперезаписаный файл. Аллокация, конечно, консистентна, размер файла правильный, но вот толку то с того? Так понятнее почему я уже не первый раз спрашиваю - а как господа с EXT4 вообще определяли что их данные - не битые? И я так и не получил ответ на этот простой вопрос. Который с учетом свойств EXT4 далеко не праздный.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от OpenEcho (?), 23-Ноя-23, 16:26
	> ext4 - самая стабильная и надежная если хранить файлы > xfs - кончается место - данные xfs_repair убивает > zfs - просто рассыпается из-за неудачного ребута сервера > btrfs - ничего сказать не могу, особо не юзал, но говорят данные теряет как xfs и zfs вместе > взятые причем полностью и починке не подлежит > > есть еще ufs2 у фряшников, так то вообще не фс, а какое-то недоразумение Какой богатый опыт !!! И как же вы с такими руками еще EXT4 не сломали ?
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	250. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от нах. (?), 24-Ноя-23, 11:32
	а как он ее сломает если в его винде - ntfs? Богатый опыт у него - чтения разной чуши в интернетах.
	Ответить | Правка | Наверх | Cообщить модератору

74. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:16
Самое прикольное за кадром осталось. Во-первых, обнаружить файлы, ссылающиеся на блоки с некорректным рефкаунтом - на данный момент около никак. Во-вторых, если метаданные уже повреждены, проблема вылезет при любом клонировании данного файла, даже с "зафикшенной" версией. Т.е. продолжайте есть кактус. Если bclone был - придётся копировать весь пул. Удачи, ребятО.
Ответить | Правка | Наверх | Cообщить модератору

	81. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 23-Ноя-23, 14:21
	> Во-первых, обнаружить файлы, ссылающиеся на блоки с некорректным рефкаунтом - на данный fsck же для трусов. zfs без него обойдется, так все бандерлоги говорят и потому это правда!
	Ответить | Правка | Наверх | Cообщить модератору

	271. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 24-Ноя-23, 14:31
	Руководство по администрированию файловых систем ZFS Solaris • Октябрь 2009 г. Проверка данных Помимо восстановления данных служебная программа fsck осуществляет проверку на отсутствие проблем в данных, хранящихся на диске. Традиционно эта задача выполнялась путем размонтирования файловой системы и выполнения служебной программы fsck, возможно, с переводом системы в однопользовательский режим. Этот случай приводит к простою, продолжительность которого пропорциональна размеру проверяемой файловой системы. Вместо явного вызова служебной программы для выполнения необходимой проверки ZFS предоставляет механизм программной проверки всего объема данных. Эта функциональность, называемая очисткой (scrubbing), обычно применяется для памяти и файловых систем в целях обнаружения и предотвращения ошибок до того, как они приведут к сбою оборудования или программного обеспечения.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 17:04
	> Руководство по администрированию файловых систем ZFS Solaris • Октябрь 2009 г. оно ж точно по-русски было написано. Т.е. васяны цитируют машинный перевод юзергайда для альтернативно-одаренных. Искренне веря что там вся правда и ничего кроме правды.
	Ответить | Правка | Наверх | Cообщить модератору

	407. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 01-Дек-23, 13:48
	Не понял юмора. Цитата из PDF на русском с сайта Оракла.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 01-Дек-23, 17:44
	Ну и ? Машиннопереведенная чушь. Вас удивляет что она оказалась на сайте оракла?
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (82), 23-Ноя-23, 14:25
	С линуксовыми такая ж фигня. Пока что-то разваливаться не начнёт, хрен поймаешь ошибку. И опять переустановка линукса, которая уже так же обязательна через некоторое время, как и переустановка венды.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

75. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от Аноним (82), 23-Ноя-23, 14:16
Такое ощущение, что тут уже линуксоидов не осталось, только представители маркетинговых отделов корпорастов, бьющихся в истерике "защищая линуксократию"
Ответить | Правка | Наверх | Cообщить модератору

84. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
Сообщение от Аноним (86), 23-Ноя-23, 14:23
ext4 gang reporting in
Ответить | Правка | Наверх | Cообщить модератору

	362. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 27-Ноя-23, 03:12
	> ext4 gang reporting in Да, расскажите как вы определяете что данные вообще не побились :). Технологией страуса чтоли?
	Ответить | Правка | Наверх | Cообщить модератору

91. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от bazanul (?), 23-Ноя-23, 14:34
ext2 для ноутбуков, для остального есть ext4
Ответить | Правка | Наверх | Cообщить модератору

97. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от Аноним (96), 23-Ноя-23, 14:51
EXT* а дети пусть балуются чем хотят.
Ответить | Правка | Наверх | Cообщить модератору

119. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–2 +/–
Сообщение от Мурат (?), 23-Ноя-23, 16:09
если кто-то выключает sync, checksum, брезгует пользоваться хотя бы раз в неделю тем же scrub, в итоге получает то, чего заслужил.
Ответить | Правка | Наверх | Cообщить модератору

	189. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
	Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:23
	Ни первое, ни второе, ни третье - от описанной х*ты не помогут.
	Ответить | Правка | Наверх | Cообщить модератору

124. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от Sw00p aka Jerom (?), 23-Ноя-23, 16:41
дедуп говорили они, спасибо поржал :)
Ответить | Правка | Наверх | Cообщить модератору

	224. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	–1 +/–
	Сообщение от Аноним (-), 24-Ноя-23, 02:36
	> дедуп говорили они, спасибо поржал :) А получился - debug, да еще в авральном порядке после релиза. Бывают в жизни огорчения. Это вы остальные их баги не видели просто. А то что вы на вашу ФС не видели - так у проприетарщиков багтрека на публику не вывешено. Это не значит что там все идеально было. Тот же NTFS одно время например наповал тер себя если диск более 2 терабайт. Там wrap случался по мере забития места - и в какой-то момент оно выносило партишн, MFT и проч - после чего это технически уже "не совсем NTFS" за отсутствием его самых критичных частей. ...а после ребута такой штуки юзер обычно огребал суровый сюрприз. И визит в data recovery lab, самому такое замахать без специфичных навыков уже душновато будет.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (282), 24-Ноя-23, 18:26
	Пруф то будет? Или у тебя обычные 294е об ратушки? Перепутал проблему mbr диска больше 2Тб с старым багом, у небольшого процента людей, заполнения больше 90% диска?
	Ответить | Правка | Наверх | Cообщить модератору

	360. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 27-Ноя-23, 02:54
	> Пруф то будет? Или у тебя обычные 294е об ратушки? > Перепутал проблему mbr диска больше 2Тб с старым багом, у небольшого процента > людей, заполнения больше 90% диска? Я честно говоря не помню всех деталей - это было в районе XP/2003 чтоли, когда диски стали к 2Тб подбираться, появился вал репортов с убитыми дисками - и MS в конце концов выкатил некий MS KB признаюший что на диске более 2 Тб может случиться врап, и тогда будет снесен партишн и MFT. И я пару таких экспонатов видел - очень неприятные в починке вещи, ибо там реально нет партишна (это еще ладно, как правило можно восстановить) - и - что хуже - MFT реально разнесен вдрызг. Интимные подробности как именно майки ЭТО достигли мне честно говоря не очень интересны, я виндой сто лет не пользуюсь. Просто прикольный обсирак когда ФС внезапно и резко дох. Если кто думает что это единственный, блин, MS KB в силу винтажности не нашелся. Зато - вот - нашелся еще прикольный напоминальник как юзеры NTFS убивали себе - https://hothardware.com/news/accessing-windows-10-icon-thras... - тоже стебная бага так то. А качество кода ntfs.sys вообще настолько легендарное что даже - вот - FAQ написали, типа https://www.diskinternals.com/ntfs-recovery/ntfs-sys/ например :). В вот таких случаях лично я вытаскивал хомякам их добро тупо зацепив ЭТО fuse'ом под линем. Тот обычно прекрасно читает все или почти все без эксцессов. Хотя иногда бывают и реально странные обосратушки, когда у NTFS часть структур слетает хз почему и как. В таком случае это ессно либо спецсофт, либо если и он не смог, testdisk/photorec.
	Ответить | Правка | Наверх | Cообщить модератору

	406. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (406), 30-Ноя-23, 06:58
	То что не помнишь прямо совершенно тебе не мешает с диким апломбом нести ересь. 2Тб это про мбр и невозможность юзать биг разделы. Баг с развалом мфт это заполнение больше 90% диска в определенных условиях и на определенном билде. Точных дата что за патчи винды стоять должны я не нашёл, но мс фикснул свой косяк. Это совершенно бриллиантли точно, потому что такой баг я кэтчнул лично на терабайтнике. Пару экспонатов тобой наблюдаемых это примерно зиро целых и несколько десятых процента. По сравнению с багами в линуховых фс - ничто. С 90х я всё поюзал из линухфс. Начиная с екстфс и всеми выходящими рейзерфс, хфс, жфс. И все они через сам тайм после загрузки пускали проверку и что-то находили. Когда чекали ошибки. А когда и просто дизастер систем. Рейзерфс раз файв наверное рассыпался, жфс пару раз, хфс как рейзер примерно улетала. Давай ещё расскажи что пара отвалов фс на сотни миллионов пользователей это ужас-ужас риали. А вот пара десятков отвалов на сотню тысчонок пользователей это рок-стейбл.
	Ответить | Правка | Наверх | Cообщить модератору

127. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от Аноним (127), 23-Ноя-23, 16:44
В FreeBSD 14-RELEASE по дефолту vfs.zfs.bclone_enabled=0 Так что, расходимся. А линуксоиды пускай страдают.
Ответить | Правка | Наверх | Cообщить модератору

	147. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от 1 (??), 23-Ноя-23, 17:56
	Тут же пишут, что ашипка непонятно где, и может вылезти даже если bclone выключен. У меня на TrueNAS truenas% uname -a FreeBSD truenas.local 13.1-RELEASE-p9 FreeBSD 13.1-RELEASE-p9 n245429-296d095698e TRUENAS amd64 truenas% zfs -V zfs-2.1.13-1 zfs-kmod-v2023100900-zfs_dd2649a68 с gentoo в виртуалочке, проблема не воспроизводится. Ну правда ZFS на ZFS - мало ли что даёт + или нуль в квадрате ...
	Ответить | Правка | Наверх | Cообщить модератору

128. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
Сообщение от 1 (??), 23-Ноя-23, 17:02
В качестве рекомендованного обходного пути блокирования ошибки предложено не устанавливать go в gentoo
Ответить | Правка | Наверх | Cообщить модератору

	143. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (143), 23-Ноя-23, 17:46
	Лучший ответ!
	Ответить | Правка | Наверх | Cообщить модератору

	163. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (153), 23-Ноя-23, 19:25
	Жаль, что не питон.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	272. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 24-Ноя-23, 14:38
	Смеяться будем, когда гентушники локализуют проблему. У меня такое же было с ext4 на рамдиске. Пришлось накинуть немножко вольтов на процессор, что бы питание приблизилось к номиналу.)
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	391. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (390), 28-Ноя-23, 19:44
	> Смеяться будем, когда гентушники локализуют проблему. У меня такое же было с > ext4 на рамдиске. Пришлось накинуть немножко вольтов на процессор, что бы > питание приблизилось к номиналу.) А вот горе оверклокер-андерклокер узнал почему свои лапки не стоит совать в DVFS если не понимаешь что и нафига делаешь и не способен валидацию работы железа произвести. Особо пикантный бонус: файлуха с чексумами в таком случае орала бы на сбой чексум оптом. А вы узнали о факапе только по его факту. Вон те то багу починят - и все вернется на круги своя. А EXT4 и его фаны и дальше будут проверять целостность данных гаданием на кофейной гуще.
	Ответить | Правка | Наверх | Cообщить модератору

	404. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (269), 29-Ноя-23, 12:20
	>> Смеяться будем, когда гентушники локализуют проблему. У меня такое же было с >> ext4 на рамдиске. Пришлось накинуть немножко вольтов на процессор, что бы >> питание приблизилось к номиналу.) > А вот горе оверклокер-андерклокер узнал почему свои лапки не стоит совать в > DVFS если не понимаешь что и нафига делаешь и не способен > валидацию работы железа произвести. А вот и очередной эксперт включил механическую психзащиту, не улавливая, к чему я это написал и зачем вон то всё делал. > Особо пикантный бонус: файлуха с чексумами в таком случае орала бы на > сбой чексум оптом. Любопытная гипотеза. Подтверждать её, естественно, знаток файлух не будет. > А вы узнали о факапе только по его > факту. Вон те то багу починят - и все вернется на > круги своя. А EXT4 и его фаны и дальше будут проверять > целостность данных гаданием на кофейной гуще. Понимаю, что вопрос про lock может засыпать всякого, но так то активничать зачем? ;)
	Ответить | Правка | Наверх | Cообщить модератору

144. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
Сообщение от Аноним (144), 23-Ноя-23, 17:48
ZFS обретает популярнось, и это хорошо. Работайте, братья!
Ответить | Правка | Наверх | Cообщить модератору

242. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+2 +/–
Сообщение от А.Н.Оним (?), 24-Ноя-23, 10:16
В FreeBSD 13.2 с последними патчами проблема воспроизводится. Временный фикс: sysctl vfs.zfs.dmu_offset_next_sync=0
Ответить | Правка | Наверх | Cообщить модератору

	251. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от нах. (?), 24-Ноя-23, 11:34
	Ну вот очень похоже что таки дело совсем не в bclone. > Временный фикс: > sysctl vfs.zfs.dmu_offset_next_sync=0 bsd only фикс. Потому что это фича из еще неопубликованного релиза. Но, кажется, можно вместо этого просто не апгрейдить пул.
	Ответить | Правка | Наверх | Cообщить модератору

	253. Скрыто модератором	+/–
	Сообщение от А.Н.Оним (?), 24-Ноя-23, 12:04
	> bsd only фикс Не только. Пишут, что в Линуксе тоже ошибка не воспроизводится, если так сделать: echo 0 > /sys/module/zfs/parameters/zfs_dmu_offset_next_sync > Но, кажется, можно вместо этого просто не апгрейдить пул. Вот это было бы интересно проверить. Но если пул уже проапгрейдили, деваться некуда. Пока что написал маленькую утилитку, которая сканит все файлы и выводит те, которые состоят из нулей.
	Ответить | Правка | Наверх | Cообщить модератору

	258. Скрыто модератором	+/–
	Сообщение от нах. (?), 24-Ноя-23, 12:58
	> Не только. > Пишут, что в Линуксе тоже ошибка не воспроизводится, если так сделать: хм, значит это hole birth снова Rebirthнулась во всей красе и bclone тут видимо непричем. как они этого б-ть добились-то?
	Ответить | Правка | Наверх | Cообщить модератору

	252. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от 1 (??), 24-Ноя-23, 12:02
	2 чая ! Ну хоть пошла техническая инфа ...
	Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

	259. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 24-Ноя-23, 12:59
	> 2 чая ! > Ну хоть пошла техническая инфа ... где инфа-то? Шаманские песни пошли.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от 1 (??), 24-Ноя-23, 13:48
	> Шаманские песни пошли. Ну есть немного ... Зато рекомендации - 1. Не апгрейдить пул 2. Если проапгрейдил - копируй данные на не проапгрейдженный пул 3. Не можешь 1,2 - используй sysctl
	Ответить | Правка | Наверх | Cообщить модератору

	285. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 24-Ноя-23, 19:24
	> Зато рекомендации - > 1. Не апгрейдить пул вот это - хорошая рекомендация, всегда ей следую! ;-) (тут главное - чтоб какая-нибудь автоматическая хрень о тебе не "позаботилась" без твоего ведома) К счастью, до работающей raidz expansion остался примерно еще годик. Авось и починят что.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от А.Н.Оним (?), 25-Ноя-23, 04:11
	Проверил пул на проблемной системе на наличие файлов, полностью или частично (только начало размером recordsize) заполненных нулями - таковые не обнаружились. "Продолжайте вести наблюдение" (с)
	Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

	312. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от Аноним (312), 25-Ноя-23, 13:37
	Сделали простой скрипт для поиска потенциально битых файлов на zfs: https://github.com/openzfs/zfs/issues/15526#issuecomment-182...
	Ответить | Правка | Наверх | Cообщить модератору

	350. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 26-Ноя-23, 20:30
	ну так себе идея считать потенциально битым любой файл с 4k нулей. У меню их есть. Да и скорость его работы "ниочинь" Это скрипт для разработчиков а не васянов пытающихся спасти свой ценный прон. Для потестить свою фс на в принципе наличие самого бага - используйте reproducer.sh, не забыв прочитать как именно его используют.
	Ответить | Правка | Наверх | Cообщить модератору

311. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
Сообщение от Аноним (312), 25-Ноя-23, 13:35
Выпустили исправление OpenZFS https://github.com/openzfs/zfs/pull/15571
Ответить | Правка | Наверх | Cообщить модератору

	343. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 26-Ноя-23, 17:01
	> Выпустили исправление OpenZFS > https://github.com/openzfs/zfs/pull/15571 это нужно но не то исправление. Увы.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+1 +/–
	Сообщение от пох. (?), 26-Ноя-23, 23:30
	Или таки то... похоже, reproducer.sh больше не работает после этого патча. Там народ пытается выдать экстремальные нагрузки чтобы увеличить вероятность срабатывания, но пока ни у кого с 15571 не получилось.
	Ответить | Правка | Наверх | Cообщить модератору

331. "В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"	–1 +/–
Сообщение от Tron is Whistling (?), 26-Ноя-23, 12:04
Весёлая история. То есть оно ещё и с bclone вообще не связано, просто вся такая НАСКВОЗЬ(C) НАДЁЖНАЯ(TM) файловая система могла при неудачном тайминге незаметно выдавать читающему нули вместо блоков при чтении. В результате чего вся эта её СКВОЗНАЯ(TM) ЦЕЛОСТНОСТЬ(C) оказывалась бесполезна. Потому что нули записывал уже читающий, а не файловая система... То есть всё это оказалось ровно так, как я с появления этой прекрасной серебряной пули и вещаю. Не спасёт она от повреждения данных системой во время чтения, до или во время записи - ровно никак. А основной источник повреждения данных - именно оно и есть.
Ответить | Правка | Наверх | Cообщить модератору

	332. "В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"	–1 +/–
	Сообщение от Tron is Whistling (?), 26-Ноя-23, 12:07
	Особо забавно было, как тонны верующих хвалились везде непревзойдённой надёжностью этого буллшита, в то время, как оно прозрачно и незаметно пороло части из них данные просто by design.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"	+1 +/–
	Сообщение от Аноним (336), 26-Ноя-23, 14:21
	Вот этот дизайн тоже не очень: "In general inodes and offsets start from 0 and work up - so almost all of the time they don't actually overflow. The problem with ext4 directory hash "offsets" is that they overflow all the time and immediately, so instead of "works unless you have a weird edge case" like all the other filesystems, it's "never works"."
	Ответить | Правка | Наверх | Cообщить модератору

	344. "В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"	+/–
	Сообщение от пох. (?), 26-Ноя-23, 17:02
	> it's "never works"." Кросивое!
	Ответить | Правка | Наверх | Cообщить модератору

	342. "В OpenZFS выявлена ошибка, которая может привести к повреждению файлов"	+/–
	Сообщение от пох. (?), 26-Ноя-23, 17:00
	> Не спасёт она от повреждения данных системой во время чтения, до или > во время записи - ровно никак. А основной источник повреждения данных > - именно оно и есть. ну вообще-то нет. Такие баги которые портят данные и при этом висят необнаруженными - редкость. В ext4 скажем уже пару лет не было.
	Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

354. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+3 +/–
Сообщение от пох. (?), 26-Ноя-23, 23:55
Ну и вкратце реальный источник ошибки - успехов местным васянам найти его "git blame" - как найдете, свистните. Тут в freebsd 12 очень нужно (к ней не подойдет 15571). При копировании файла большинство реализаций cp (а заодно tar и дофига кто еще) используют специфический метод для обнаружения в нем дыр и создания вместо нулей нераспределенных блоков которые копировать или сохранять незачем. Это НЕ чтение и сравнение с нулем, такое бы сработало как надо, но читать пару гигабайт ничего чтобы убедиться что там нули - немного глупо, и у большинства fs есть для этого отдельная фича в lseek. Вот в ее реализации - обмишулились чуток. Да, во времена иллюмоса еще. Или даже швятога sun - но это неточно. И если дергать SEEK_HOLE на файле половина которого еще висит где-то в кэшах и не долетела до диска - можно ненароком найти несуществующую. (так что таки привет hole_(re)birth - реинкарнировалась десять лет спустя, падла) Т.е, существующие данные потерять таким образом _нельзя_, повреждена будет только копия. Чтобы получить такую поврежденную копию - нужно скопировать файл ДВАЖДЫ - второй раз - сделав копию копии, причем достаточно быстро чтобы вторая копия еще не успела до конца дописаться - тогда третья оказывается несовпадающей. Рефлинки никак с этим не связаны. Если там и есть баг - он отдельный. Нули необязательны как признак поврежденного файла - может точно так же неправильно сработать и SEEK_DATA (т.е. наоборот - вместо законных нулей получить билиберды) dmu_offset_next_sync связана только тем, что это оказалось вредное "улучшение", не улучшавшее как думали, а ухудшавшее производительность при множественной параллельной записи (т.е. просто оставляло больше шансов на возникновение race, но он таки возникает и при 0, просто надо сильнее грузить систему) Сборка игого попала под раздачу именно потому что без конца копирует одни и те же файлы, их много, и параллельная сборка сильно грузит fs, игого и рач не виноваты, странно но тоже факт.
Ответить | Правка | Наверх | Cообщить модератору

	363. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (319), 27-Ноя-23, 03:20
	> Вот в ее реализации - обмишулились чуток. Да, во времена иллюмоса еще. Или > даже швятога sun - но это неточно. И если дергать SEEK_HOLE на файле половина > которого еще висит где-то в кэшах и не долетела до диска - можно ненароком найти > несуществующую. (так что таки привет hole_(re)birth - реинкарнировалась десять > лет спустя, падла) Шикарно. Детектив, а не добавите эти детали с подробностями расследованоя в новость? Чисто в исторических целях, все же, шикарное расследование. Оно достойно быть в новости а не где-то в ж...е.
	Ответить | Правка | Наверх | Cообщить модератору

	369. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 27-Ноя-23, 12:43
	с этим обращайтесь к администрации сайта. Но она и так неплохо живет, незачем новости редактировать. Надо бежать быстрее удалять.
	Ответить | Правка | Наверх | Cообщить модератору

	380. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Аноним (380), 28-Ноя-23, 04:34
	> с этим обращайтесь к администрации сайта. Но она и так неплохо живет, > незачем новости редактировать. В принципе ты и сам можешь отредактировать, если яваскрипт отсюда выполнять не обломно, под новостью есть "исправить". Но да, без JS не работает. > Надо бежать быстрее удалять. Фороникс вон вывесил продолжение саги. А опеннет - прошляпил, хотя вон тот гражданин повторил мое достижение - и таки обставил фороникса на, наверное, сутки, устроив детективу досрочный спойлер.
	Ответить | Правка | Наверх | Cообщить модератору

	405. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от пох. (?), 29-Ноя-23, 17:07
	> обломно, под новостью есть "исправить". Но да, без JS не работает. так оно ж премодерируется. Т.е. точно так же сиди и жди пока пчьолы прилетят.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от Tron is Whistling (?), 27-Ноя-23, 10:10
	Да, тут 146% можно обгитблеймится что-то найти. Вполне возможно, что связка нескольких багов. Но беда в том, что оно уже фигову тучу времени это счастье таскает, просто массово вылезло при правильном схождении звёзд. А у кого-то уже давно вылезло на редко используемых данных, но пока ещё не замечено, потому что вера в сквозную(c) целостность(tm) и редко используемые данные. Короче, лишний раз убеждаюсь в том, что трогать это не стоило :)
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	370. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."	+/–
	Сообщение от нах. (?), 27-Ноя-23, 12:48
	> Но беда в том, что оно уже фигову тучу времени это счастье таскает там раза четыре этот код ковыряли (и это помимо глобальной переделки в open версии) причем именно в режиме "тааак... а тут вот это надо проверять или уже необязательно". Ну и в общем в очередной пятый раз оказалось что - обязательно. А то что от этого всего зависит - оно в других местах и тоже уже не такое как было изначально. Поэтому нельзя даже угадать - число багов было четным, или просто никто не замечал. > Короче, лишний раз убеждаюсь в том, что трогать это не стоило :) ну а что стоило? Не всем же подходит ntfs.
	Ответить | Правка | Наверх | Cообщить модератору

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

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