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

"В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS"	+/–
Сообщение от opennews (??), 26-Май-23, 23:36
В опубликованном в конце апреля выпуске ядра Linux 6.3 выявлена ошибка, приводящая к повреждению метаданных файловой системы XFS.... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59204
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–5 +/–
Сообщение от Аноним (1), 26-Май-23, 23:36
Такое ощущение, что все эти xfs, btrfs и прочие – лишь игрушки. Ждём нормальный и стабильный ext5.
Ответить | Правка | Наверх | Cообщить модератору

	2. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+9 +/–
	Сообщение от лох (?), 26-Май-23, 23:40
	В ней-то точно багов не будет, ага
	Ответить | Правка | Наверх | Cообщить модератору

	3. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+10 +/–
	Сообщение от Аноним (3), 26-Май-23, 23:42
	Баг в ядре, чукча. xfs наверно единственная годная из всего зоопарка помимо ext.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	4. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от Аноним (4), 26-Май-23, 23:48
	И в чём её годность заключается?
	Ответить | Правка | Наверх | Cообщить модератору

	5. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (3), 27-Май-23, 00:01
	Она довольно надежная и производительная.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+5 +/–
	Сообщение от Аноним (6), 27-Май-23, 00:05
	"Довольно", да.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–8 +/–
	Сообщение от Аноним (8), 27-Май-23, 00:19
	Деградирует xfs куда больше ext4. У ext4 основная проблема фрагментация свободного пространства которая эээ может быть весьма значительной. Ну и время доступа к большим каталогам какое-то не здоровое (фрагментация опять же), но это вроде у всех. У меня xfs только и делала, что портила файлы всю свою историю, пока пытался использовать, поэтому теперь только оправданные эксперименты. Вроде f2fs, но её тоже бездумно пихать нельзя и слишком уж много ограничений.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–5 +/–
	Сообщение от Аноним (3), 27-Май-23, 00:22
	Из розетки часто дергал? Умирающий хард-убожка? Перегревающийся полуразбитый ноут?
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+6 +/–
	Сообщение от birdie (ok), 27-Май-23, 00:38
	Я давным давно работал в компании, где backup сервер крутился под RHEL 5 с XFS. В один день, придя на работу, мы не досчитались 200GB backup'ов, которые тупо исчезли. Я дал доступ по SSH с root одному из разрабов - он больше часа ковырялся и ... ничего не нашёл. Каталог с десятками файлов по несколько гигабайт просто исчез. Следов удалённых файлов не было в метаданных, как будто исчез (или обнулился) целый блок инод. Ах, да, и место освободилось. Ошибок XFS в dmesg не было. Нет, это не было взломом или insider work - почему я это знаю, потому что modification time и какие-то метаданные (размер? не помню уже) у головной директории был таким, какими они должны были бы быть, если бы подкаталоги не были удалены, если бы они вообще никогда не существовали. Это вручную было сделать невозможно (кроме как dd if=/dev/zero of=/dev/partition_with_xfs) - так сказал разработчик. После этого мы переехали на ext3, потом ext4 и не имели ни одной проблемы. Ситуация с тех пор улучшилась, XFS стала default FS для RHEL7, но осадок остался.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–4 +/–
	Сообщение от Аноним (3), 27-Май-23, 01:02
	Страшилка интересная. Не иначе космическое излучение. Во времена RHEL 5 xfs была вполне стабильной. На уровне ext3 уж точно.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+7 +/–
	Сообщение от Гиря (?), 27-Май-23, 08:18
	>Во времена RHEL 5 xfs была вполне стабильной. На уровне ext3 уж точно. интересно, стабильна потому-что стабильна, чел сверху хоть рассказал свою историю успеха, а у вас какое-то словоблудие.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (184), 27-Май-23, 21:43
	а какая может быть история, если у него, предположим, не было ни одного факапа? Типа, " - Cлушайте мой случай: За 20 лет использования ничего не потеряли" - так, что ли? Случившаяся "история успеха" - это когда что-то произошло. Это отдаленно напоминает ситуацию с хорошим и плохим админом - окружающие всегда видят как с ж.пой в мыле работает плохой админ (" - Молодец, трудяга, не зря зарплату получает - вон, постоянно что-то ремонтирует то тут то там! Пообедать некогда.") и совсем не знают что такого делает хороший админ (" - Дармоед! Ведь всё и так работает и не ломается. Даже не знаю в каком кабинете он сидит и что там делает, но зарплату, нахлебник, получает!". Т.е. твой собеседник не может тебе ничего рассказать "за работу хорошего админа", если у него всё работало, работает и ни разу не возникали проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:19
	Сосайтник, дай конкретные и объективные измеримые критерии стабильности ФС. И пруфани, что XFS - стабильная ФС.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	294. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 01:48
	> Страшилка интересная. Не иначе космическое излучение. Во времена RHEL 5 xfs была > вполне стабильной. На уровне ext3 уж точно. Особенно затирание файлов нулями. Это почти мировая константа. Я думал что к 2.6.28 это, наконец, починили. Примерно 10 лет спустя от момента как проблема заявила о себе. Но нет, потом еще дочинивали ЭТО дополнительно. Представляете?! Мушкетеры, i++ лет спустя.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	45. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от gleb (?), 27-Май-23, 08:09
	это какой год? я плотно использую xfs с 2002, причём на довольно больших (от едениц Тб в 2002 по десятки Тб в настоящее время). В 2002 -- 2008 наблюдалась проблема с обнулением открытых на запись файлов при внезапном пропадании питания). Других потерь занных не было никогда. Я бы всё-таки пошукал-бы, не было ли в этой ситуации человеческого фактора. Или отказа/сбоя, если метаданные хранились на другом устройстве.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	56. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Sergey (??), 27-Май-23, 09:22
	Про время и обнуление файлов на ХФС подтверждаю. Но в те времена Шапка еще не допилиа ХФС и не рекомендовала ее юзать. Что касается того рассказа, я после слов : дал доступ по SSH разрабу, читать перестал. Они откуда знают как работает ФС и что это такое. Они даже маке толком осилить не могут.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (97), 27-Май-23, 11:40
	Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая система;))(
	Ответить | Правка | Наверх | Cообщить модератору

	104. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 11:57
	> Ну он сделал ls, не увидел файлов и сказал что глюкнула файловая > система;))( Он использовал xfs_db и другие утилиты для отладки.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 11:56
	> это какой год? ~ 2004 > В 2002 -- 2008 наблюдалась проблема с обнулением открытых на запись файлов > при внезапном пропадании питания). Очень похоже на наш case.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	230. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (230), 28-Май-23, 16:50
	сервер без ups?
	Ответить | Правка | Наверх | Cообщить модератору

	251. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Омоним (?), 28-Май-23, 20:38
	А вот у вас система никогда в кору не падала? Например, из-за сбоя железа, или ошибки в драйвере?  меня вот бывало. И знаете, UPS при этом не помогает совершенно никак.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от kilua (?), 27-Май-23, 08:33
	Души убитых процессов мстят...
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	95. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:35
	XFS не журналирует данные, только метаданные. Эта ФС годна только для файлопомоек, которые не жалко обнулить.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	144. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от лютый арчешкольник (?), 27-Май-23, 15:05
	>Эта ФС годна только для файлопомоек, которые не жалко обнулить. ext3-4 во всех режимах кроме одного тоже ) а с ним превращается в помойку по скорости
	Ответить | Правка | Наверх | Cообщить модератору

	318. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 19:09
	>>Эта ФС годна только для файлопомоек, которые не жалко обнулить. > ext3-4 во всех режимах кроме одного тоже ) а с ним превращается > в помойку по скорости Тут очень хорошо написано за что некоторые из нас любят BTRFS. Его логика эквивалентна полному журналированию - но без вот этого вот пеналти по скорости работы. Это одно из ключевых достоинств технологий на основе COW. За это воздается странноватыми свойствами, но вот этот вот момент оно обыгрывает безупречно. На самом деле идея простая: если всю площадь ФС сделать подобием журнала, записывать дважды уже не придется.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Ананоним (?), 27-Май-23, 01:48
	У меня раздел ext4 1GB уже 9 лет живёт, я начинаю тихо охреневать от фрагментации. Нужна программа дефрагментации. Некоторые директории открываются 30 секунд.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	33. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от totem (?), 27-Май-23, 04:45
	Это не фрагментация. "Ext4 умеет на ходу увеличивать размер структур на диске, в которых хранится список файлов и директорий в ней, но не умеет уменьшать. Поэтому если создать в директории много файлов, а потом удалить, она останется большой. При доступе к такой директории приходится читать эти фрагменты, которые ещё и оказываются разбросаны по диску там и сям. Это медленно." Создай новую директорию и перенеси файлы туда. При этом блоки данных этих файлов на диске останутся на своих местах.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Виктор Федорович Полторищенко (?), 27-Май-23, 14:03
	e2fsck не решает эту проблему посредством опции optimize_extents?
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от totem (?), 27-Май-23, 04:47
	Посмотри ls -ld . в "плохой" директории И в хорошей.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	132. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от ZloySergant (ok), 27-Май-23, 14:16
	>Нужна программа дефрагментации. anyfs-tools
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	168. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (168), 27-Май-23, 19:20
	mkfs.ext4
	Ответить | Правка | Наверх | Cообщить модератору

	178. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 27-Май-23, 20:43
	>Нужна программа дефрагментации. е4defrag - штатная программа. Не знали ? Правда есть недостаток-иноды плохо дефрагментирует,хорошо только экстэнты.Поэтому иногда проще перенести каталог на внешний диск а потом обратно, как делали в старые времена.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	31. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Амаяк Акопян (?), 27-Май-23, 03:36
	Подозреваю, что для больших каталогов подойдёт включение опции dir_index
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	43. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 08:03
	xfs не деградирует. Проблемы со скоростью доступа начинаются только на очень сильно забитых больших разделах. Если осталось процентов 10 свободного места, тогда да, торимоза станут вполне заметны.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	67. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (8), 27-Май-23, 10:36
	10% от 100тб это 10тб если что, ещё можно минимум пару файлов впихнуть. Сколько миллиардов файлов считается "очень сильно забитым" и почему ext4 норм, лишь бы не в 1 каталоге? Да и тогда вполне предсказуемо.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 01:40
	> xfs не деградирует. Проблемы со скоростью доступа начинаются только на очень сильно > забитых больших разделах. Если осталось процентов 10 свободного места, тогда да, > торимоза станут вполне заметны. Стереть на нем торент без преаллокации... никогда не видали файло на 4.7 гига (стандартный DVD) стираемый 2 минуты? Тот неловкий момент когда удалять файлы чуть ли не дольше чем скачивать :)
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	150. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 27-Май-23, 16:30
	xfs на нескольких десятках серверов работает в данный момент, с десяток разделов на каждом с постоянными изменениями. все работает таким образом уже не знаю сколько лет на Ubuntu, больше 8 точно.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	152. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (8), 27-Май-23, 16:47
	Конечно, веселье начинается, когда паника или power outage прилетает. Но, судя по успехам xfs, достаточно и перезагрузки. Десятки серверов иногда всё же необходимо перезагружать для обновления, хотя бы раз в сезон, то что они у тебя больше 32 сезонов отпахали без обновлений тоже ничего хорошего (железо столько не живёт кстати)
	Ответить | Правка | Наверх | Cообщить модератору

	153. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (8), 27-Май-23, 16:49
	Кстати о повреждениях ты узнаешь сильно постфактум, скорее всего, когда исправных бекапов уже не останется. Вот и доверяй потом подобным помойкам.
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

	24. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 27-Май-23, 01:46
	ФС, которая молча хавает битые данные, не имея чексумм на данные и метаданные - не может быть надежной.Btrfs, ZFS - надежные ФС. XFS, ext4 - нет.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	28. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (28), 27-Май-23, 02:28
	https://wiki.archlinux.org/title/XFS#Checksumming
	Ответить | Правка | Наверх | Cообщить модератору

	35. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от DEF (?), 27-Май-23, 05:11
	Чексуммы только на метаданные и только с убогим алгоритмом crc32. На сами данные никаких чексум нет, что у ext4, что у XFS.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 27-Май-23, 20:57
	>На сами данные никаких чексум нет, что у ext4, что у XFS. Есть, только аппаратные,самого жёсткого диска, и уже давно.Сейчас уже выжали с жёстких все что можно,особенно с учётом черепичной записи.Это страшно,но уже используется алгоритмы по зашумленному сигналу предсказывающие вероятно идеальный сигнал.Есть поэтому у некоторых производителей серверные жёсткие с усиленной контрольной суммой,там до 3 байт ошибок на 4 мгб ченить могут на аппаратном уровне.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 01:56
	> Есть, только аппаратные,самого жёсткого диска, и уже давно. Там вообще-то не чексуммы а FEC - но вот там если он не выдюжил, вариантов обычно два. Оно либо отдаст наверх IO error - UNC, либо отдаст сектор "как вышло" после FEC. В зависимости от дури фирмвари железки. Со стороны ФС и райдов проблема в том что они в результате зачастую не знают какая копия верная. Штуки типа btrfs получают очевидный плюс: на какой копии данных чексум сошелся, та и правильная. Обычный RAID вообще может вытворять что угодно если вместо полной кончины девайсы стали допустим битые данные выгружать. Дальнейшее unspecified - и если чексум данных не было вы можете довольно долго не замечать это, пока в ФС что-то не развалится фатальным образом. Как показал опыт с btrfs - пойти не так может совершенно все. - Может глючить RAM и в конечном итоге это тоже проблема. - Может глючить CPU и это тоже ведет к проблемам. - Может глючить чипсет или контроллер RAID и их фирмвар (где применимо). - Может быть глючный провод от диска до контроллера (SATA/SAS/etc). - Фирмвари девайсов могут вытворять все что угодно и даже больше. Иногда это превосходит самые дикие допущения ФСов. Скажем потерять большой регион в 16-64 мега при внезапном слете питания? Всего лишь SSD кантовал RMW/GC а тут питание слетело или сглючила фирмварь. Некоторые конфигурации типа Btrfs @ RAID1 даже имеют шансы. А вот просто RAID1 совсем не готов что 2 копии будт, как живые, только - уже вот несимметричные, и догадайтесь какая из 2 верная. А как об этом всем узнать? А вот запустить файлуху с чексуммами в эксплуатацию. И сразу столько открытий чудных, на тему глючного железа, которое как живое, но раз в час/день/месяц/год пару битиков загаживает. > Сейчас уже выжали с жёстких все что можно,особенно с учётом черепичной записи. Zoned в btrfs приветы передавал. Правда это для host-managed актуально. > производителей серверные жёсткие с усиленной контрольной суммой,там до 3 байт ошибок > на 4 мгб ченить могут на аппаратном уровне. У почти всех заметно более мощный FEC. Типа эн байтов на каждые 4096 сектор. Собственно с 512 на 4096 перешли чтобы улучшить соотношение data/FEC. Но наружу это если и лезет то только как UNC или как мусор вместо данных если фирмварь решила вместо UNC отдать "уж что вышло". Это однако совсем не аналог чексум ФС, потому что end-to-end проверки корректности работы железа не получается и вооон то можно прошляпить. А с btrfs вон там глючный чипсет заметили, тут глючный шнурок, там глючная RAM, а там и вообще проц кривой был, а там девайс не сообщал UNC но отдавал труху. Коллекция глюкастиков основательно пополнилась. Хорошо когда чексуммы данных есть.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 29-Май-23, 07:47
	>Со стороны ФС и райдов проблема в том что они в результате зачастую не знают какая копия верная. Это как ? Я не беру в качестве примера ниже 5 рэйд.Там же Рида-Соломона коды корректировки,если код не совпадает значит диск дегрейд...Так уже есть рэйды где 3 диска может развалиться и данные не потеряться.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 01:42
	>> не знают какая копия верная. > Это как ? Я не беру в качестве примера ниже 5 рэйд. Ну вот так. RAID1: читаем обе копии по одному смещению. Опа, они разные! И чего теперь? Мы знаем что в этом месте проблема, но понятия не имеем какая из копий правильная. В случае чексум данных все упрощается: если есть копия с неверной и копия с верной чексумой, ок, вычислили гонщика. Так можно определить проблемный накопитель/контроллер/канал/провод... > Там же Рида-Соломона коды корректировки, В именно RAID 5 так то всего лишь XOR. Если взять 3 девайса, и 2 блока, b1 и b2, это пишется как b1, b2, b1^b2 (XOR b1 с b2). XOR интересен тем что при вылете b1 или b2 он восстанавливается всего лишь XOR второго блока с parity. Это просто, быстро, оверхед 1/3 при 3 девайсах, меньше если девайсов больше, но - переживает только отказ 1 девайса. Если нужно больше, это уже RAID6 и вот там дополнительный parity уже будет рид соломоном. Это позволяет починить вылет и 2 устройств за раз. > если код не совпадает значит диск дегрейд... Для RAID5 это не сработает: мы видим что b1 ^ b2 != parity но понятия не имеем который из них неверен. Для RAID6 это уже можно попробовать. Но это ценой 2 полноразмерных блоков четности. Т.е. минимум 4 стоража, при этом оверхед 50%. Как RAID1 только тормознее и хуже. В случае например btrfs на RAID1 (и даже DUP на 1 стораже) видит какая из копий неверная и фиксит из правильной. Для большего числа дисков RAID6 может уже иметь смысл а RAID5 становится опаснее т.к. за время ребилда не должен скончаться ни 1 стораж. У btrfs там кстати плюс есть: знает что аллоцировано а что нет. И на полупустом пуле оно ребилдить будет сильно меньше - только реально занятые блоки, сколько уж их там на проблемном девайсе было. В зависимости от - так ребилд может быть сильно резвее. Это же касается изъятия/замены девайсов, scrub, смены схемы хранения, уменьшения ФС и т.п.. Это и есть смысл терпеть те неудобства. Безгеморное управление, можно решения переиграть, они не высечены в камне. Не нравится тот уровень RAID - конвертим в другой, лишь бы места в новом фоормате хватало для фактически записанных данных. Можно даже "мягкую" конверсию: старые блоки останутся как есть, а новые с новой схемой. Вполне валидно для той механики. А на обычном RAID такие вещи лучше даже не пытаться... как угодно но это next gen технологий хранения. > Так уже есть рэйды где 3 диска может развалиться и данные не потеряться. Ну да. Triple parity raid. Правда, взамен придется хранить ТРИ набора блоков parity и это не менее чем 5 девайсов, иначе бессмысленно. В принципе соотношение DATA/FEC ничем таким не ограничено, даже в RAID1 если сделать 10 копий блока то до 9 можно потерять. Проблема только в том что эффективность схемы == 1/10. Нужно ли оно такое? Врядли. Потому что не спасает от сбоев проца, рам и проч например, все 10 могут оказаться испорченными и оверхед того не стоил.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 30-Май-23, 06:36
	Вы рассматриваете устаревшие схемы раид.Сейчас эффективность и надёжность подняли, в качестве примера читайте на хабре статью "Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных". Там для коррекции сбоя в отдельной области применили страйпы,т.е очень быстрая локализация ошибок. Вообще очень передовая разработка была- работает система при развале 3!!! дисков из 7 в массиве. Очень показательно что разработку этой компании в наглячку стали обходить-всплыли заявки на патенты за полгода (как в Японии в 80 х), появились в других странах аналогичные !! патенты и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	319. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 19:48
	> Вы рассматриваете устаревшие схемы раид. Устаревший - относительное понятие. Если скажем всего 2 диска есть в энной системе, то чего кроме RAID 1 там будет такой уж смысл иметь? И чем это будет лучше? Особенно если с чексумами, так что мы видим на какой из 2 копий был сбой и можно осмысленно фиксить сбои. Чексуммы не так много места занимают зато улучшают свойства схемы хранения. А в случае btrfs можно еще и при душняке с местом просто добавить, просто +1 девайс. Любой. Какой был. И будет 3-девайсовый RAID1. > Сейчас эффективность и надёжность подняли, Кто, где, КАК ЭТО ПОЮЗАТЬ НА МОИХ СИСТЕМАХ? Сферические сказки про супербатарейки "где-то там" уже несколько надоели, извините. Я вот хочу нормальные технологии у себя на компах, ноуте, одноплатниках и проч. А не "где-то там". > в качестве примера читайте на хабре статью "Как разработчики сидели в Петербурге и тихо ели > грибы, а потом написали ОС для систем хранения данных". Проблема в том что поедатели грибоа - где-то там. И операционкой у меня Linux везде. А RAID может быть не центром вселенной а 1 из фич, повышающей надеженость, до кучи. Just because I can. В этом случае меня парит чтобы менеджмент был ненапряжный, дурацких требований и допушений - минимум, а чексуммы, вот, еще и диагностируемость повышают, хайлайтя при случае проблемный хардвар. В ряде случаев это early warning вообще, когда я конечно играю в рулетку, но в режиме когда теорвер уже за меня а не против меня. В мире хлипкого железа где народ хочет емко, быстро и за копейки - это сильный аргумент. Потому что расплатой за это является текучесть, сыпучесть, глюкавость, минимальные margins, ... и по другому это можно и не заметить. А потом пожалеть когда данные - в хлам. > Там для коррекции сбоя в отдельной области применили страйпы,т.е очень быстрая > локализация ошибок. Ох да, мне в btrfs примерно то же самое тоже очень нравится. Разок как-то на ноуте бэд вылез, да еще под метаданными. Очень приятно при этом "csum error, corrected" получить а не разлет системы в хлам. Только вот этот хайтек - у меня на ноуте. В повседневной работе. А не у каких-то мужиков из питера с кастомной операционкой где-то там. И вот что б вы мне имели предложить лучше? Ваш EXT4 который от такого под метаданными рассыпался бы вдрызг и я бы ос переставлял? Ну спасибо, только это - не хайтек и не апгрейд. Ну да, там 1 диск и DUP как схема. И - вот - конкретный пример почему оно так. Без всяких хабр. > Вообще очень передовая разработка была- работает система при развале 3!!! дисков > из 7 в массиве. И чего? Почитайте теорию - и поймете что в принципе FEC может исправлять любой процент ошибок. Вопрос в объеме оверхеда на хранение FEC и вычислений. Ну и осмысленности полученной схемы для тех или иных задач. А что если у меня дисков всего 2-3? Там очевидно тот номер не пройдет. Более того - а у этих мужиков можно как в btrfs, просто подоткнуть 8-й диск, если 7 стало мало? И чтоб без жесткого рестрайпа всей штуки вотпрямща? > Очень показательно что разработку этой компании в наглячку стали обходить-всплыли > заявки на патенты за полгода (как в Японии в 80 х), Японские патенты 80х должны бы уже истечь. На патенты обычно 25 лет срок. > появились в других странах аналогичные !! патенты и т.д. Большая часть патентов на технологии FEC либо истекла либо будет вышиблена prior art при ближайшем рассмотрении. И вы все это рассказываете тому кто умеет строить схемы избыточности под любые нужды. Но мы же про линуха и то что в майнлайне. В свое время там летали забавные патчи - весьма забавный, если не ошибаюсь, ридсоломон с конфигуряемым объемом избыточности и соответственно соотношением емкости. Но столько счастья видимо народу не требовалось и тема заглохла. А вон те разговоры в пользу бедных... мне они зачем? И как это все поможет актуальные мне конфиги улучшить по свойствам? Никак? Ну тогда "let it float by itself, f...g piece of iron".
	Ответить | Правка | Наверх | Cообщить модератору

	331. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 09:22
	>Японские патенты 80х должны бы уже истечь. На патенты обычно 25 лет срок. Это я про  книгу одного из бывших  министров промышленности,он покаялся в 15 году.Он писал как химичили и тырили технологии где возможно.И было дано указание патентному бюро  тоже мошенничать- на интересную патентную заявку специально задними числами оформляли приоритет заявку на японскую фирму. Потом  Американцам это дело надоело- и поймали специально неправильно описанными  патентами на воровстве,ВТО не хило Японию оштрафовало.....и куча японских фирм.
	Ответить | Правка | К родителю #319 | Наверх | Cообщить модератору

	341. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 31-Май-23, 20:34
	> Это я про  книгу одного из бывших  министров промышленности,он покаялся в 15 году. Это слишиом экзотичный референс чтобы на него универсально ссылаться без пояснений. > Он писал как химичили и тырили технологии где возможно. Да вообще так все делают. Вопрос в легальном статусе. Скажем, переизобретать лампочку накаливания каждому в своей норке независимо было бы довольно неэффективно по ресурсам. С другой стороны и совсем уж фига изобретателю как-то неправильно. В этом смысле патенты несколько адекватнее копирайта, там еще и платить за продление надо - на память о чем есть такая чудная штука как Google Patents. Кроме всего прочего это кладезь годных идей, на половину из которых их авторы все же забили, не осилив коммерциализировать. Но это ж не значит что про них надо просто забыть? Expiry патента по причине "не оплачено" прозрачно намекает :) > И было дано указание патентному бюро  тоже мошенничать- на интересную патентную > заявку специально задними числами оформляли приоритет заявку на японскую фирму. А интерес в этом какой? Да и патенты обычно сразу в эн юрисдикциях хреначат на что-то реально стоящее. Первым делом в штатах, у них рынок большой и денег много. > Потом  Американцам это дело надоело- и поймали специально неправильно описанными   > патентами на воровстве,ВТО не хило Японию оштрафовало.....и куча японских фирм. Заднее число имеет свойство вылезать - когда кто-то все же приперся в суд и/или нашел prior art. И если в россии объективный арбитраж штука спорная, то в большей части более-менее цивилизованных стран это чревато как минимум сливом судебного процесса с треском и неслабыми выплатами. Правда, даже в штатовских патентах - их оформляют совсем не гении и типовой клерк может сдуру выписать патент на что-то весьма общее и неконкретное. Правда, в суде это все же быстренько сливается.
	Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

	324. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (324), 31-Май-23, 01:43
	Чувствуется опыт у человека
	Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

	335. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 11:26
	> Чексуммы только на метаданные и только с убогим алгоритмом crc32. На сами > данные никаких чексум нет, что у ext4, что у XFS. А там и НЕ НУЖНО более извращенные алгоритмы.90% Метаданных  в  XFS занимают стандартный блок 64 кб и изобретать велосипед не надо,хватает перекрестной проверки  с веретификацией Log SequenceNumber.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	348. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 02:20
	Чексуммы _данных_ верифицируют работу оборудования end to end. И ловят множество факапов которое вон то "should never happen" просто не заметит. А потом всякие кадры рассказывают страшилки про плохие файлухи рассыпающиеся "сами по себе". На поверку сейчас большая часть таких репортов оказывается связана с глюками железа выходящими далеко за допущения типовых файлух. Единственное известное исключение это рейзер где убиение тома fsck - "known issue" :)
	Ответить | Правка | Наверх | Cообщить модератору

	78. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Rootlexx (?), 27-Май-23, 11:04
	Эта проблема решаема на другом уровне через dm-integrity.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	107. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 12:07
	Это должно решаться на уровне ФС, которая для этого и предназначена - гарантировать целостность данных.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 02:24
	> Эта проблема решаема на другом уровне через dm-integrity. Проблема в том что получается сложное, стремное месиво, которое при нужде переконфигурить - убиться можно. И когда вместо этого "btrfs device add -> +100500 места в пуле" вот извините но я хочу видеть управление сторажами вот так - а не тот кошмарик. Со всеми этими dm, LVM и прочими получилось как в IPSec. Ну а btrfs сойдет за вайргад такой себе тогда. Хотя bcachefs на эту роль был бы еще убедительнее :)
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	189. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Kuromi (ok), 27-Май-23, 22:40
	Вы так говорите как будто бы ZFS и BTRFS были всегда, а вот дураки разработчки ext* не догадались добавить чексуммы. На самом деле что ext, что xfs или jfs (помните?) - очень старые файловые системы. И ext и xfs получили кучу модернизаций за прошедшие годы (нынешний xfs вообще мало похож на оригинальный), но их основа - довольно древняя, невозможно там навернуть таких новшеств как в "созданной с нуля" btrfs. И ничего люди жили с незапамятных времен с ext и xfs.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	252. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (252), 28-Май-23, 21:28
	>  Она довольно надежная и производительная. Бугага. Переполнения LVM раздера переводит ее в RO и нарушению митаданных, спасает только reboot.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	258. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 00:08
	> Она довольно надежная и производительная. Ее легендарную надежность с протиранием "ненужных" файлов нолями для безопасности трудно забыть. И так цать лет к ряду. И все остальное не сильно лучше. Еще и тормозная что капец при работе с метаданными. А вон то - это то что редхат получает разогнав всех спецов блочного уровня и заменив их на каких-то индусов. Если обратить внимание, все известные кадры вокруг ФС и блочного уровня из редхата ушли так или иначе. Последним был Bacik, после него там вообще ни 1 известного кадра не оталось, какие-то нонеймы известные хзчем.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	14. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от Виталий (??), 27-Май-23, 00:40
	Скажу от себя: её основная годность - более эффективная поддержка гигантских дисков объёмом больше 4х терабайт. Ext4 да, невероятно надёжная и хорошо зарекомендовавшая себя файловая система, НО, на дисках объёмом больше 4х терабайт могут всплывать различные ограничения и замедление производительности (сильно дольше будет отзываться). Что про файловую систему XFS, то она специально создана под гигантские диски, чтобы откликалась быстро не зависимо от того, как много файлов на ней навалено, и т.п. У меня на сервере диск 6 терабайт, работает на XFS. Если коротко - XFS первым делом нужна для гигантских файлопомоек. Для всего остального Ext4 за уши хватит.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	44. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от gleb (?), 27-Май-23, 08:04
	все ext* начисто сливают при конкурентной работе.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (8), 27-Май-23, 14:08
	Всех сливают? Ну да. На самом деле, по производительности и фичам ext4 уступает только ntfs, но ты и так прекрасно это знаешь. Зато вот по надёжности и фрагментируемости она куда лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от пох. (?), 27-Май-23, 10:01
	> Что про файловую систему XFS, то она специально создана под гигантские диски вот сейчас SGI неистово завертелась в гробу. Нет, конечно же, те 600мегабайтники были "гигантские", чугуниевая хреновина в full size 5" слот выглядит довольно угрожающе, при ее включении корпуса из листовой стали (на ней тогда тоже не экономили) ощутимо подпрыгивали, но вот если про объемчик занимаемых данных, а не места в корпусе, то тот у них был немного маловат по нонешним меркам.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	259. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 00:13
	> вот сейчас SGI неистово завертелась в гробу. Торент качни, хотя-бы гигов на 200, лучше на забитый диск и без преаллокации, чтоб фрагментировался уж точно хорошенько. А теперь попробуй его стереть... не забудь засечь сколько времени это займет. У остальных ФС данное действо заканчивается за какие-то сильно более разумные врмена. Или на большие ФС большие файлы и тем более их фрагментация - не предполагаются? :)
	Ответить | Правка | Наверх | Cообщить модератору

	11. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (11), 27-Май-23, 00:32
	zfs норм
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (3), 27-Май-23, 00:49
	Капризная и жрущая много ресурсов для своей работы ФС. На BSD иногда есть смысл ее использовать. В линуксе ее функциональность составляется из комбинации ФС и LVM.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от DEF (?), 27-Май-23, 01:42
	>В линуксе ее функциональность составляется из комбинации ФС и LVM. В линуксе ее функциональность составляется использованием Btrfs.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от n00by (ok), 27-Май-23, 06:45
	С той разницей, что я заливал командой dd 2 гигабайта на один из накопителей в ZFS RAID0 и система осталась жива (какие-то файлы побило, но пул восстановил), а BtrFS сама собой рассыпалась.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от gleb (?), 27-Май-23, 07:57
	btrfs нельзя *восстанавливать* через dd, если в системе есть ещё хоть одно устройство с тем-же UUID. Потому, что btrfs автоматически подхватит клонируемое устройство, объеденит его с уже имеющимся и в результате будет "ой". И об этом написано везде. Аршинными буквами.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 09:07
	А где у меня написано, что я ВОССТАНАВЛИВАЛ btrfs? Но намёк по поводу аршинных букв понял, исправляюсь: "BtrFS САМА СОБОЙ рассыпалась."
	Ответить | Правка | Наверх | Cообщить модератору

	69. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 10:45
	а делал ЧТО, если лил данные через dd?
	Ответить | Правка | Наверх | Cообщить модератору

	90. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 11:19
	> а делал ЧТО, если лил данные через dd? В каком месте Вам не понятно "заливал командой dd 2 гигабайта на один из накопителей в ZFS RAID0" и как Вы это привязали к "а BtrFS сама собой рассыпалась"?
	Ответить | Правка | Наверх | Cообщить модератору

	59. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от мшефд (?), 27-Май-23, 09:46
	Другими словами, человек _специально_ _портил_ данные на одном из элементов RAID-массива для проверки его, этого RAID-массива, устойчивости.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	51. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от DEF (?), 27-Май-23, 08:55
	Нуб, диски клонировать нужно через send/receive, а не dd.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	53. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 09:06
	Прежде чем оставлять своё особо ценное мнение, хорошо бы научиться читать. Даю ещё один шанс, выделив ключевое слово: "я заливал командой dd 2 гигабайта НА один из накопителей в ... RAID0 " Такая операция гипотетически разрушает массив, но в случае ZFS он выжил из-за дублирования метаданных.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 10:50
	ой, ёёёй. запись произвольных данных на один из элементов raid, тем более raid0?! это что за удивительное тестирование? тут ни одна фс и ни одна из равновидностей raid не даст никаких гарантий и место хранения метаданных не спасёт. Подозреваю, что при повторении эксперимента даже и на zfs будет давать сильно разные результаты.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 11:17
	> ой, ёёёй. > запись произвольных данных на один из элементов raid, тем более raid0?! Да. > это что за удивительное тестирование? тут ни одна фс и ни одна > из равновидностей raid не даст никаких гарантий и место хранения метаданных > не спасёт. Гарантий вообще никто не даст, читайте "AS IS" в лицензии. Потому проверять следует самому. > Подозреваю, что при повторении эксперимента даже и на zfs будет давать сильно > разные результаты. Вот это и есть -- удивительное тестирование.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от gleb (?), 27-Май-23, 12:34
	>Вот это и есть -- удивительное тестирование. удивительное -- не то слово, я бы применил "идиотское". без обид, просто потому, что результат заведомо будет случайным, непредсказуемым и главное, неповторяющимся.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 14:05
	>>Вот это и есть -- удивительное тестирование. > удивительное -- не то слово, я бы применил "идиотское". без обид, просто > потому, что результат заведомо будет случайным, непредсказуемым и главное, неповторяющимся. Пожалуй, не буду спорить. Если опыт не ставить, но утверждать о неких его результатах - это можно назвать и идиотизмом. Тем более, что Вы сами так предложили. ;) Но всё же рекомендую впредь проводить хоть какие-то эксперименты, как это делал я.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 14:58
	> впредь проводить хоть какие-то эксперименты, как это делал я. эксперимент должен планироваться так, чтобы давать повторяемые результаты, иначе зачем он нужен? из общих соображений, запись в произвольное место массива, это нештатная и крайне маловеротяная в реальном мире ситуация, защиты от которой никто не делает. Её имитация не может даже ответить на вопорс, "выживет ли массив". Потому что вероятность, как у блондики, смотря, куда попадёт, и от используемой файловой зависит слабо.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 16:05
	>> впредь проводить хоть какие-то эксперименты, как это делал я. > эксперимент должен планироваться так, чтобы давать повторяемые результаты, иначе зачем > он нужен? Вы ведь не пробовали повторить, но утверждаете, что результаты не повторятся. > из общих соображений, запись в произвольное место массива, это нештатная и крайне > маловеротяная в реальном мире ситуация, защиты от которой никто не делает. И вероятность Вы не рассчитывали. По факту я случайно записал установочный образ вместо флешки на накопитель. Следом провел эксперимент по восстановлению, внимательно почитал документацию и всё получилось. > Её имитация не может даже ответить на вопорс, "выживет ли массив". > Потому что вероятность, как у блондики, смотря, куда попадёт, и от > используемой файловой зависит слабо. Можно примерно рассчитать, какой процент данных повредится безвозвратно. Но делать я это не буду - Вы же свои утверждения никак не доказываете.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	275. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 29-Май-23, 09:25
	> из общих соображений, запись в произвольное место массива, это нештатная и крайне > маловеротяная в реальном мире ситуация, защиты от которой никто не делает. Делают,делают.Для видиопотоков.Там с жестких выжали все что можно-но и требования по надежности снизили.Читайте на хабре статью "Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных". Там для сбоя в отдельной области применили страйпы. Вообще очень передовая разработка была- работает система при развале 3!!! дисков из 7 в массиве.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	170. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (168), 27-Май-23, 19:24
	После этого нубика и поперли из росы не заплатив и дав повод для многолетних рыданий
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	214. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 28-Май-23, 08:43
	После этого работники Росы принялись анонимно клеветать, что меня откуда-то попёрли. Тогда как я был обычный пользователь, кто решал за "разработчиков" то, что те не могли.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 28-Май-23, 22:26
	>тут ни одна фс и ни одна из равновидностей raid не даст никаких гарантий и место хранения метаданных не спасёт. Читайте статью (Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных),на Хабре ,просвещайтесь. Работает при выходе 2 дисков из массива (6.2) или 3 !! (RAID 7.3) дисков.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	75. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:02
	>выжил из-за дублирования метаданных В btrfs метаданные тоже дублируются. Режим DUP назвыается.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	85. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 11:13
	>>> диски клонировать нужно через send/receive, а не dd >> хорошо бы научиться читать >> я заливал командой dd 2 гигабайта НА один из накопителей в ... RAID0 > В btrfs метаданные тоже дублируются. Это называется "подмена предмета обсуждения" и является довольно унылым приёмом демагогии.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:39
	Ну так не демагогствуй. Свою кривую память протести на битроты и контроллеры на data flush. Btrfs рассыпается только если железо давно рассыпалось и его место на помойке. От этого даже ZFS не спасет.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 14:07
	Я не составлял багрепорт о том случае с BtrFS, мне не до того было. Ты судишь на основании систематический ошибки выжившего? Поздравляю. Весомый аргумент к твоей экспертизе, помимо неумения читать и фантазировать на тему железа, когда по факту был накопитель с ионисторами.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 02:09
	> Я не составлял багрепорт о том случае с BtrFS, мне не до > того было. Ты судишь на основании систематический ошибки выжившего? Поздравляю. Весомый > аргумент к твоей экспертизе, помимо неумения читать и фантазировать на тему > железа, когда по факту был накопитель с ионисторами. Ну окей, тогда я буду вместо него. И скажу что поймал в btrfs пару жирных багов - в RC - в моих конфигах. А еще в отличие от вас я все же оформил баги, потеребил разработчиков, получил очень быстрый, крутой и компетентный ответ. И теперь этих багов нет. Более того - судя по рассылкам и чатам других ФС у них с багами все примерно так же. Т.е. сыпется все что угодно. И обычно по достаточно хорошей причине, типа мало того что некорректной работы оборудование - так еще в месте где это выходит за допущения дизайна. Скажем ни 1 фс не готова к произвольным глюкам проца. Однако ряд глюков проца может, вот, вызывать асимметрию счета чексум на чтение и запись и в этом случае детектируем. Но это работает для рандомных сбоев а не перманентного повреждения проца симметричного на сбой и при чтении и при записи (с таким процом все как правило падает до того и проблема отпадает сама собой). И это не про ошибку выжившего а про чудаков думающих что все баги во всех случаях реально отловить. Даже в штуке типа EXT4 до сих пор бывают приколы. А уж в дизайнах типа btrfs и zfs - нет, можно конечно рассказывать легенды, но, имхо, это будут сказки. Начиная с того момента что zfs вообще сторонний модуль и никто ничего не гарантирует на его счет со стороны кодеров ядра. Более того - после вгрузки такого модуля багрепорт на майнлайн вообще не особо вкатишь и это как бы грабли. Конечно можно рассказать что все всегда должно работать идеально и это не должно требоваться, но тут мы возвращаемся к ошибке выжевшего.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 30-Май-23, 07:52
	> А еще в отличие от вас я все же оформил баги, > потеребил разработчиков, получил очень быстрый, крутой и компетентный ответ. И теперь > этих багов нет. Порадуете ссылочкой на багзиллу? Если захотите сослаться на боязнь деанона, расскажите, куда заливали образ в пол гигабайта с битой файловой системой, что бы его круто посмотрели спецы. И каким образом заливали. По умолчанию у среднестатистического пользователя нет запасного накопителя - он просто удаляет систему и ставит родную Бесяточку. > И это не про ошибку выжившего а про чудаков думающих что все > баги во всех случаях реально отловить. Априори программа на императивном языке содержит ошибки, её корректность требует доказательств. Частные случаи вроде Вашего для обобщения требуют доказательств по индукции. Всему этому учат в школе.
	Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

	260. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 01:23
	> побило, но пул восстановил), а BtrFS сама собой рассыпалась. Нельзя ли конкретнее? 1) Какие были конфигурации ФС? 2) Что конкретно было сделано? 3) Что случилось с точностью до сообщений об ошибке? 4) "Пул восстановил" очень растяжимое понятие, кмк. Это точно scrub проходит и не разваливается без долговременных последствий?
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	307. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 30-Май-23, 08:17
	> 4) "Пул восстановил" очень растяжимое понятие, кмк. > Это точно scrub проходит и не разваливается без долговременных последствий? Набираю в поисковике "восстановление zfs пула", читаю по второй ссылке документацию Оркала: # zpool status   pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss.         Returning the pool to its state as of Wed Jul 14 11:44:10 2010         should correct the problem.  Approximately 5 seconds of data         must be discarded, irreversibly.  Recovery can be attempted         by executing 'zpool clear -F tpool'.  A scrub of the pool         is strongly recommended after recovery. Т.о. scrub является частью процедуры восстановления и вопрос теряет смысл. Сложности там, если и были, то с затёртой таблицей разделов. Не помню уже, что именно с ней делал. Но ничего сверхъестественного, иначе бы записал. > Нельзя ли конкретнее? > 1) Какие были конфигурации ФС? > 2) Что конкретно было сделано? > 3) Что случилось с точностью до сообщений об ошибке? Не вижу смысла всё это уточнять, когда ZFS я поднял. Был сделан вывод о непригодности BtrFS "для дома". Можно просто считать меня нубом и обывателем - вполне годное основание для вывода. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	328. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 31-Май-23, 04:31
	> Набираю в поисковике "восстановление zfs пула", читаю по второй ссылке документацию Оркала: Я наверное непонятно выразился, пардон. Мой апстрим - майнлайн, мне интересно чтобы он, и его технологии, используемые мной (включая btrfs) работали хорошо. На внемайнлайновые вещи (включая zfs) это НЕ распостраняется. Если интересно почему: я плотно подсел на апстрим, опенсорс и пользуюсь возможностями удобного, быстрого фикса багов путем пинка конкретных тушек с подробными данными о проблеме, вплоть до точного коммита (если я смог в это). Это возможно только с чистым майнлайновым кернелом актуальной версии. В этом контексте я бы послушал что с btrfs случилось. Что делалось, в каких обстоятельствах (конфиг, версия ядра, etc), если это что-то характерное для актуальных версий ядер, все такое. Что за сообщения об ошибке и т.п.. Это конечно в чисто научных целях, но я люблю всякие странные эксперименты, анализ того что я вижу и это иногда срабатывает. Для себя это срабатывало хорошо, в ядре не осталось ни 1 бага который бы мешал мне жить. Мало ли, вдруг сработает и в подобных случаях - улучшив технологию которую я использую. Это был бы правильный вариант "спасибо" создателям оной с моей стороны. Разумеется без гарантий и обязательств, я не саппорт. > Сложности там, если и были, то с затёртой таблицей разделов. Не помню > уже, что именно с ней делал. Но ничего сверхъестественного, иначе бы записал. Таблицу разделов не особо сложно чинить как по мне. > Не вижу смысла всё это уточнять, когда ZFS я поднял. В моем случае смысл изложен выше. Ну как бы дело хозяйское. > Был сделан вывод о непригодности BtrFS "для дома". На мой вкус это либо неверный, либо неактуальный вывод, идущий вразрез с моими выводами - у меня btrfs много где, в том числе и "дома" (на компах, лаптопе и все такое). Если я не прав, хотелось бы каких-то более убедительных технических деталей (на основании которых я попытаюсь предпринять действия чтобы мои заявления стали ближе к правде). > Можно просто считать меня нубом и обывателем - вполне годное основание для вывода. ;) Это было бы проще всего. Но этот мир так устроен что правда редко бывает простой или приятной, законы Мерфи в технике имеют место быть. К тому же так вышло что я отличаю "n00by" от фонового шума и накопленные данные свидетелствуют что это было бы слишком упрощенной картиной мира.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 31-Май-23, 15:35
	> В этом контексте я бы послушал что с btrfs случилось. Что делалось, > в каких обстоятельствах (конфиг, версия ядра, etc), если это что-то характерное > для актуальных версий ядер, все такое. Что за сообщения об ошибке > и т.п.. Это конечно в чисто научных целях, но я люблю > всякие странные эксперименты, анализ того что я вижу и это иногда > срабатывает. Я поступил ровно так же, как в случае с ZFS. Набрал в поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить. Так на моём месте поступил бы средний пользователь, если он не полный чайник. Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа не дождался - как всегда внезапно понадобился. Случилось, что при старте ОС неожиданно оказалась BtrFS немонтируема, в том числе в R/O, что несколько раз спасало. А ZFS я сам сломал. >> Был сделан вывод о непригодности BtrFS "для дома". > На мой вкус это либо неверный, либо неактуальный вывод, идущий вразрез с > моими выводами - у меня btrfs много где, в том числе > и "дома" (на компах, лаптопе и все такое). Если я не > прав, хотелось бы каких-то более убедительных технических деталей (на основании которых > я попытаюсь предпринять действия чтобы мои заявления стали ближе к правде). "Я использую" и "посоветую другу для дома" не одно и тоже. Если надо просто ФС для SSD, то проще F2FS или EXT4 для консерваторов. Если надо снапшоты, более-менее ёмкий RAID с кешем на NVMe - то как бы и нет выбора кроме ZFS. Если надо "на работу" - так там есть админ, пусть он убеждает.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 31-Май-23, 22:39
	> Я поступил ровно так же, как в случае с ZFS. Набрал в > поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить. Я бы не назвал идею что-то делать с фс по советам из интернета от хз кого удачной идеей. Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше. При этом крайне желательно самому понимать что и зачем делаем и насколько оно соответствует ситуации. Иначе риск получить фигню высокий. С любой ФС. Одна из причин по которой мне рефлинки нравятся - возможность слепить "копию" образа восстанавливаемой файлухи - и прогнать допустим fsck на "копии" дешево и сердито. При этом реально оно конечно создается в жалкие секунды для образа пару терабайт, а потом занимает места только на дельту относительно оригинала. А нужно это вот как раз на случай если результат попытки починить до моунтабельного состояния не понравится. Так бывает, увы. Много с чем и почему, так что запасной план на этот случай хорошая идея. > Так на моём месте поступил бы средний пользователь, если он не полный чайник. Средний пользователь при должной прыти заканчивает у вооон тех господ из датарекавери лабы. С кратной накруткой за прыть, сделавшей восстановление данных сложнее а потому - в разы дороже. Мои знакомые если не уверены в себе меня теребят, но тому есть причины, эн вполне успешных рекавери сессий и общее понимание азов того ремесла :) > Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа > не дождался - как всегда внезапно понадобился. А это был что? HDD? SSD? Ну и там достаточно было снять метаданные без данных с него, у btrfs есть такой вариант, спецом для багрепортов и воспроизведения багов. Только метаданные - сильно легче и их хранить не особо напряжно. Но да, это слегка продвинутости, для тех кто настроен с вылезшей проблемой зарубиться. Т.е. нормальных опенсорсников. > Случилось, что при старте ОС неожиданно оказалась BtrFS немонтируема, в том числе > в R/O, что несколько раз спасало. А ZFS я сам сломал. Оказалась немонтируема - печально, спору нет. Но с технической точки зрения хотелось бы понять что произошло. Скажем какое сообщение было, etc. А так фигня у всех случается. > "Я использую" и "посоветую другу для дома" не одно и тоже. Эм... тут есть достаточно неопределенный фактор "квалификация друга". Если это хомяк с виндой, он может и не врубиться в продвинутости типа снапшотов, рефлинков и всего такого, если едва одуплял основы иерархии это слишком круто. А если это мощный *никсоид... ему я и с data recovery при такой нужде помогу практически "за интерес". Я предпочитаю дружить с вон теми и поэтому в целом это не проблема, есть группка друзей использующих достаточно продвинутые технологии и обменивающихся опытом. > Если надо просто ФС для SSD, то проще F2FS или EXT4 для консерваторов. У меня F2FS не пережил power loss/system reset tests когда я оценивал идею затолкать его как ФС для одноплатников. Он быстрый, дружественный к флешу... а еще он феерично разлетается без особых усилий. И даже fsck далеко не всегда может его собрать. И если это не получилось, плана Б особо и нету. Кроме скорости и дружественности к флешу он ничего предложить не имеет. Если этого достаточно - ну, окей. И все же снапшоты системы это круто и удобно, делает основную систему чем-то похожей на виртуалки, если кто понимает multiverse и альтернативные таймлайны из sci-fi, он оценит возможность итеративно догнать систему до нужного состояния даже если изначально эксперимент не прокатил за весьма обозримое время. А в файлухах без снапшотов undo нету. Можно LVM сделать но это муторно и работает хуже. На самом деле все просто: на F2FS надрывается по сути 1 кодер в самсе. На котором еще и ksmbd на минуточку. Может ли 1 чел столько нагрузки тянуть - вы наверное поняли. Это продукт корейской галерной промышленности. Со всеми вытекающими. Но да, дизайн дружественный к флещу. Впрочем, btrfs тоже флешу не враждебен, например. Для флеша логика CoW достаточно удобна, а в zoned режиме оно вообще само FTL напоминает по логике. Ext4? Ну он как бы есть, как бы работает, на идеальном железе даже не особо убиваем, а если что-то все же испортилось, fsck его все же обычно чинит. Быстрый ли он? Смотря что с ним делать. И его основной минус - он не парится что будет с данными. Чексум нет. С полным журналом он тормоз, а без - можно смесь старого и нового состояний файла получить, это обычно непригодно к использованию. > Если надо снапшоты, более-менее ёмкий RAID с кешем на NVMe > - то как бы и нет выбора кроме ZFS. ЧСХ и с оным и с btrfs (там они через bcachefs кэш делают) на этом прикольно налетает, когда затертый до дыр SSD начинает чудить. Реакция SSD на окончание ресурса это такой отдельный достаточно забавный топик. Ну и вот советовать друзьям такое - реально разве что в убунте. Где проблемы стороннего модуля майнтайнеры порешают. Без этого - очень круто когда не маунтится системная файлуха потому что сторонний модуль отъехал, аж 2 раза. И тут в зависимости от юзера возможны варианты. К тому же вон те например свежую виляшку какую хотят, или еще что - значит с свежим кернелом. Так то они есть в бэкпортах и прочем но вот как там ZFS себя чувствует... использовать друзей как лабораторного мыша тоже как-то такое себе имхо. Я btrfs'а продвинутым советую, тем что сможет его плюсы оценить. Прозрачно обрисовав что сие с свежими кернелом. А любители старины типа 2.6.32 вроде поха, разумеется, успеха с этой технологией не достигнут. > Если надо "на работу" - так там есть админ, пусть он убеждает. Ну, я сам себе админ. Впрочем и сборщик образов систем и фиксер системных проблем. Это как раз та культура самообслуживания которая зародилась в опенсорсе. И использование вот именно возможностей, именно опенсорса. Когда при проблеме я могу гораздо более продвинуто диагностику сделать, а при острой нужде и патч для себя попытаться скроить. Вот так опенсорс получает пойнт. А если им пользоваться как виндой... ну и в чем профит? ;)
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от Аноним (11), 27-Май-23, 10:35
	> В линуксе ее функциональность составляется из комбинации ФС и LVM. Спасибо, кэп. Собственно zfs так и появилась. С дедубликацией по сути всего 3 ФС: zfs, btrfs, xfs. Последние две нестабильные. Вот и весь выбор. Снапшоты, copy-on-write, сжатие, репликация - весь фарш есть. Надежность уровня production (что не отменяет необходимость бекапов, как и везде). А лишняя (конкретно в данном случае) прослойка LVM не нужна. Ставить zfs в старый ноут 500ГБ hdd 4ГБ ram смысла конечно нет. Но уже для домашней файлопомойки вполне.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	138. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 27-Май-23, 14:44
	thin lvm, потому что иначе снапшоты будут ни разу непохожие на те что у zfs. А это - внезапно, "капризное и много ресурсов требующее для своей работы". Причем заметно более капризное и ненадежное чем zfs. И еще и крайне неудобное в управлении. Понадобилось тебе выделить отдельную фс с другими параметрами монтирования под какой-то специфический проект - zfs create pool/mount/point А теперь опиши все костыли и подпорки с thin lvm - предположим даже что места там с избытком и я в этом create не попросил чего странного - например, зарезервировать мне место чтоб оно точно не кончилось вместе с каким /var/log/trash Единственное (но надо признать наиболее типовое) в чем этот вариант удобнее zfs - это рутинное увеличение пула не имеющего избыточности (или имеющего средствами железа). Но это потому что ZoL.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	47. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (47), 27-Май-23, 08:17
	Сложная в освоении и память жрет побольше некоторых.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	139. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от пох. (?), 27-Май-23, 14:46
	знаешь, если две команды zfs и zpool тебе сложно - я боюсь представить что тебя ждет когда ты столкнешься с lvm, где их аж пять и все имеют совершенно зубодробительные синтаксис и семантику. Память жрет поменьше чем надо бы - потому что вариантов кроме оставить половину системе там в современных версиях нет. Но за счет ARC может что и выиграет даже.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (47), 27-Май-23, 15:15
	Меня ждет btrfs.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от пох. (?), 27-Май-23, 16:49
	если тебе даже zfs сложно оказалось осилить - она тебя не дождется.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (47), 27-Май-23, 18:17
	Чего там ждать? mkfs.btrfs и все. Никаких zpool и прочего не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	278. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 29-Май-23, 10:06
	> Чего там ждать? mkfs.btrfs и все. Никаких zpool и прочего не нужно. о ужас, набрать zpool вместо mkfs ? В общем, степень адекватности опеннетчиков уже очередное дно пробила.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 30-Май-23, 08:24
	Это называется "когнитивная ригидность" в психологии и "синдром утенка" у местных экспертов. Мне было проще собрать модули zfs и spl, чем читать man mount.)
	Ответить | Правка | Наверх | Cообщить модератору

	261. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 01:28
	> если тебе даже zfs сложно оказалось осилить - она тебя не дождется. Btrfs заметно проще, приятнее и дружественнее в управлении. Однако чтобы с btrfs стоит почитать ман и понять основы ее устройства. Тогда dos и donts станут более очевидны. А так оно просто работает. В сложных случаях можно живьем отловить разработчков btrfs и в отличие от zfs они даже могут дать дельные советы, в отличие от zfs'ных с их саморекламой и рассказами почему именно збс быть не может (как будто это кого кроме них интересует).
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	277. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 29-Май-23, 10:05
	> Btrfs заметно проще, приятнее и дружественнее в управлении. Покажите пальцем, в каком месте? Что именно вам сложно и неприятно в банальном управлении zfs ? То что у нее не кончаются метаданные в самый неожиданный момент? > В сложных случаях можно живьем отловить разработчков btrfs и в отличие от zfs они даже могут > дать дельные советы, в отличие от zfs'ных с их саморекламой вас обидели разработчики zfs? Покусились на святое?
	Ответить | Правка | Наверх | Cообщить модератору

	295. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (295), 30-Май-23, 02:12
	> Покажите пальцем, в каком месте? Добавление, замена, изъятие девайсов, рестрайп на ходу, все такое. Можно просто подоткнуть девайс если места мало. Или даже временно расширить хранилку под разовое действо, а потом вынуть добавленые девайсы. Или даже передумать насчет схемы хранения. И все это парой команд, логично, ненапряжно, шустрее чем можно было бы ожидать - благодаря backrefs и дизайну с блочными группами оно может трекать что реально аллоцировано и кантовать только это. Это управление ФС > Что именно вам сложно и неприятно в банальном управлении zfs ? То > что у нее не кончаются метаданные в самый неожиданный момент? Ну для начала мне сложно out of tree файлухой пользоваться. Это сразу +100 к системным граблям и траблам с репортом багов в майнлайн. Еще я нахожу очень странным что дедуп только с ломовым жором ресурсов - и более никак. Финт с "reflinks" мне в этом плане очень понравился: это по смыслу стопроцентный дедуп блоков, всего лишь. Когда копия изначально на 100% дедупнута относительно оригинала. Мне нравится гибкость дизайна, типа схемы хранения DUP для 1-дисковых систем. Это намного лучше лечилова про энтерпрайз, блаблабла, и позволяет прикрутить в достаточно странные применения, типа одноплатников или ноута с 1 диском. Повышает надежность системы на этом всем. Вместо рассказов про правильное железо. Это сильно лучше чем ничего. ZFS под такие допущения не делался, так что если это не энтерпрайзная файлопомойка была... а представляешь, снапшоты например актуальны на "системном диске" а вовсе и не файлопомойке. Ну или вон к роутеру 3-терабайтник с btrfs прицеплен. По скорости как ext4, плюс-минус, RAM и CPU трескает умеренно, хорошо когда фича масштабируется вверх и вниз. И иногдя я хочу именно карманный вариант героя. > вас обидели разработчики zfs? Покусились на святое? Ммм... скорее их обидели разработчики btrfs. В сравнении. Просто взаимодействие с btrfs'ными понравилось сильно больше. Люблю когда взаимодействия конструктивные, мощные, с работой над проблемой а не рассказами о том кому что (не)нужно, вилянием окороком и маркетингом. Хороший дизайн в маркетинговом булшите не нуждается. А так было бы интересно увидеть что Кент сделает, с учетом эксплуатации btrfs. Но это не быстрая история. Когда такие штуки быстро делались...
	Ответить | Правка | Наверх | Cообщить модератору

	291. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Май-23, 01:09
	А топик как раз о том как все годно в XFS получилось? :)
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	17. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–4 +/–
	Сообщение от Виталий (??), 27-Май-23, 00:49
	Для тех, кто не понимает суть, объясняю: XFS - это файловая система, предназначенная для гигантских файлопомоек (больше 4х терабайт), с которыми она работает эффективней и отзывчивей. BTRFS - файловая система для SSD-дисков и для системы. Её главная фишка - встроенная возможность создавать слепки состояния, и можно их использовать для откатывания к предыдущему состоянию в случае чего, и ещё куча других возможностей.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	19. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (3), 27-Май-23, 01:06
	xfs - Файловая система, производительность которой не зависит от количества и размера файлов. btrfs - Нестабильный комбайн. Снапшоты можно делать средствами LVM сто лет в обед. И остальную кучу возможностей тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 01:31
	>btrfs - Нестабильный комбайн Экспертное мнение от диванного эксперта подъехало. Надо же, а Facebook, Synology, SUSE, Red Hat и не знали.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (38), 27-Май-23, 07:32
	Red Hat плотно сидит на XFS
	Ответить | Правка | Наверх | Cообщить модератору

	265. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (265), 29-Май-23, 02:28
	> Red Hat плотно сидит на XFS А ей просто не на чем больше. Разработчики остальных (и блочного уровня) побегли с редхата в другие компании. У Ext4 свои девы, btrfs вообще занят монстром типа facebook. И что им было брать? JFS чтоли? Или рейзер, разносящий тома в хлам fsck'ом? :) Не, там есть еще всякие NILFS но это весьма нишевые и подзаброшенные штуки.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от Олег (??), 27-Май-23, 13:08
	Советую почитать форум синолоджи, а также кучу тем а проф форумах, где люди теряли файлы все с brtfs Xfs иногда любит lost and found Mdadm очень не любит бэд блоки, прям ахиллесова пята Zfs и ext4 сейчас живее живых
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	266. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (265), 29-Май-23, 02:29
	> Советую почитать форум синолоджи, а также кучу тем а проф форумах, где > люди теряли файлы все с brtfs Лучше поотвисать в рассылках и чатах с разработчиками ФС. И узнаете что такое случается у всех. А разница в основном в возможностях парирования, раннего обнаружения, или если все же что-то пошло не так - багфисков.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от gleb (?), 27-Май-23, 08:00
	xfs, прежде всего, надёжное хранилище, хорошо работающее при конкурентном доступе (многопоточность/многопользовательскость). btrfs вполне хороша и от детских болезней, похоже, избавилась (тьфу-тьфу). Снапшоты lvm это сильно (совсем) не одно и то же, что в btrfs. Область применения снапшотов btrfs очень сильно шире.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	29. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Xo (?), 27-Май-23, 02:41
	А ext4 для ssd разве не подойдёт?
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	30. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Виталий (??), 27-Май-23, 02:48
	Подойдёт, главное настроить правильно подключение в /etc/fstab. Я о том, что BTRFS на жёстких дисках тормозит, и поэтому для BTRFS крайне желателны именно SSD.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от gleb (?), 27-Май-23, 08:01
	btrfs весьма приятна, но вот по поводу ssd... к сожалению, усиление записи никто не отменял. Впрочем, плюсы btrfs обычно, перевешивают.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 09:41
	"Амплификация" в данном контексте это не "усиление", правильнее переводить как "чрезмерная запись".
	Ответить | Правка | Наверх | Cообщить модератору

	71. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 10:53
	что в лоб, что по лбу. и не чрезмерная запись, а именно лавинообразное увеличение числа физических записей, так что, таки усиление.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 11:27
	Сила там в амперах, надо полагать?
	Ответить | Правка | Наверх | Cообщить модератору

	112. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 12:36
	> Сила там в амперах, надо полагать? в секторах на байт.
	Ответить | Правка | Наверх | Cообщить модератору

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

	141. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 14:51
	>Вообще-то в школе учат, что в случае электронных устройств сила измеряется в амперах. А если ими кидаться - тогда в ньютонах. да неужели? и да, *усиление* в амперах нормальные люди ну никак не измеряют. хотя выразить при желании, конечно, можно.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 15:56
	>>Вообще-то в школе учат, что в случае электронных устройств сила измеряется в амперах. А если ими кидаться - тогда в ньютонах. > да неужели? Высшая школа тоже школа. Но вроде закон Ома изучают и в обычной на уроках физике. > и да, *усиление* в амперах нормальные люди ну никак не измеряют. Нормальные люди подменяют "сила там в амперах, надо полагать?" на удобное им и приписывают оппоненту? > хотя выразить при желании, конечно, можно. Коэффициент усиления транзистора - это отношение токов коллектора и базы.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (28), 27-Май-23, 23:19
	>>> Вообще-то в школе учат, что в случае электронных устройств сила измеряется в амперах. А если ими кидаться - тогда в ньютонах. >> да неужели? > Высшая школа тоже школа. Но вроде закон Ома изучают и в обычной на уроках физике. А при чем тут закон Ома? Вообще-то, *сила* измеряется в Ньютонах. А вот *сила тока* - в Амперах. Средняя школа передает привет. Но ни то ни другое не имеет отношения к write amplification, что можно перевести как "умножение записи", т.к. речь идет об увеличении количества записанных данных по сравнению с оригиналом. "Усиление записи" тоже будет корректно, но это уже буквальный перевод, который не так хорошо отражает суть эффекта. И да, внезапно, не всякая сила измеряется в Ньютонах.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 28-Май-23, 07:52
	>>>> Вообще-то в школе учат, что в случае электронных устройств сила измеряется в амперах. А если ими кидаться - тогда в ньютонах. >>> да неужели? >> Высшая школа тоже школа. Но вроде закон Ома изучают и в обычной на уроках физике. > А при чем тут закон Ома? Вообще-то, *сила* измеряется в Ньютонах. А > вот *сила тока* - в Амперах. Средняя школа передает привет. Почитайте внимательно самое первое предложение в цитате - там и про электронные устройства, и про Ньютоны. > Но ни то ни другое не имеет отношения к write amplification, что > можно перевести как "умножение записи", т.к. речь идет об увеличении количества > записанных данных по сравнению с оригиналом. "Умножение", пожалуй, годится вместо "усиления". Но в русском языке таким словом зачастую называют что-то хорошее (приумножить), потому я считаю "чрезмерная запись" уместнее. > "Усиление записи" тоже будет корректно Вы так полагаете, поскольку не изучали ТОЭ, ФОЭТ и прочие удивительные аббревиатуры? Не шили ППЗУ с УФ стиранием? Вот там после нескольких циклов записи-стирания приходилось увеличивать ток в надежде, что получится залить очередную прошивку. Вот это можно зазвать усилением записи. И совершенно внезапно SSD собраны на основе ППЗУ (ЭСППЗУ). > но это уже буквальный перевод, который не так хорошо отражает суть > эффекта. Точнее, путает. Тогда уж лучше оставить "амплификация" как в оригинале. Обывателя непонятное испугает, а специалист поймёт.
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	267. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Май-23, 03:33
	> Вы так полагаете, поскольку не изучали ТОЭ, ФОЭТ и прочие удивительные аббревиатуры? > Не шили ППЗУ с УФ стиранием? Вот там после нескольких циклов > записи-стирания приходилось увеличивать ток в надежде, что получится залить очередную > прошивку. Вот это можно зазвать усилением записи. И совершенно внезапно SSD > собраны на основе ППЗУ (ЭСППЗУ). Тут пришел другой аноним и ему интересно 1) А как вы именно больше _тока_ вгоняли? Повысив напряжение программирования? 2) Как вы в современном флеше вообще ток контролировать собираетесь? Это все рулится state machine на кристалле чипа флехи, она сама обеспечивает нужные параметры стирания и программирования (2 разных процесса, оба требуют). А повышенный вольтаж - начиповым charge pump'ом делается. Машина состояний его сама включает по мере надобности и наружу это вообще не вывешено. > Точнее, путает. Тогда уж лучше оставить "амплификация" как в оригинале. Обывателя непонятное > испугает, а специалист поймёт. Амплификация - более менее устоявшийся термин. Хотя на самом деле даже в инглише есть небольшая коллизия. Скажем read amplifier чаще всего имеет в виду характерную микросхему на блоке голов, а вовсе не то что можно было подумать из тех объяснений.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	309. Скрыто модератором	+/–
	Сообщение от n00by (ok), 30-Май-23, 08:41
	>> Вы так полагаете, поскольку не изучали ТОЭ, ФОЭТ и прочие удивительные аббревиатуры? >> Не шили ППЗУ с УФ стиранием? Вот там после нескольких циклов >> записи-стирания приходилось увеличивать ток в надежде, что получится залить очередную >> прошивку. Вот это можно зазвать усилением записи. И совершенно внезапно SSD >> собраны на основе ППЗУ (ЭСППЗУ). > Тут пришел другой аноним и ему интересно > 1) А как вы именно больше _тока_ вгоняли? Повысив напряжение программирования? Ну я ж написал "в надежде"... в т.ч. что не потребуется объяснять про нелинейность ВАХ и лавинообразный пробой. > 2) Как вы в современном флеше вообще ток контролировать собираетесь? Это все > рулится state machine на кристалле чипа флехи, она сама обеспечивает нужные > параметры стирания и программирования (2 разных процесса, оба требуют). А повышенный > вольтаж - начиповым charge pump'ом делается. Машина состояний его сама включает > по мере надобности и наружу это вообще не вывешено. Вот и я примерно так подумал когда увидел, а потом выяснил, что на самом деле эксперт по флешам назвал "усилением записи" запись лишних байт.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	329. Скрыто модератором	+/–
	Сообщение от Аноним (-), 31-Май-23, 04:40
	>> 1) А как вы именно больше _тока_ вгоняли? Повысив напряжение программирования? > Ну я ж написал "в надежде"... в т.ч. что не потребуется объяснять > про нелинейность ВАХ и лавинообразный пробой. Я другой аноним имхо нежели тот кто начал этот субтред. Про вах полевиков я в курсе, но детали имплементации структуры ячеек в первобытных EEPROM представляю лишь очень приблизительно, особенно на тему кто именно там ток ограничивал (сам полевик, какие-то структуры на чипе, или что там, и какие у этого всего ВАХ "суммарно"). А еще я встречался с креативным использованием физики EEPROM/Flash - и мне такие вещи по вкусу. Так что можно сказать что я "коллекционирую" такие знания. > Вот и я примерно так подумал когда увидел, а потом выяснил, что > на самом деле эксперт по флешам назвал "усилением записи" запись лишних байт. Ну да. Это по английски называется "write amplification" или "write amplification factor". Там это тоже не сказать что сильно удачное название, сталкивается с подобной терминологией, и уповает на декодирование из контекста. Ну вот мало людям букв и слов, генерят коллизии.
	Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

	57. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от Аноним (57), 27-Май-23, 09:40
	ext4 с коэф.записи 4 * на коэф.записи 1 для smr_hdd, сравниваем с btrfs с коэф.записи 26 * на коэф.записи 4 для ssd ~= 100   т.е. типовой 300-разовый tlc ssd можно будет переписать реально только 3 раза. Нуачо, хм, "нормальное" такое коммерческое решение. :)))
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	68. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (11), 27-Май-23, 10:42
	Еще ни разу не видел чтобы у SSD закончился ресурс (если это не баг конечно). Один экземпляр уже через трое рук прошел с 2012 года и до сих пор трудится.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от n00by (ok), 27-Май-23, 11:31
	У меня из двух Тошиб 2010 года одна померла, стояли в массиве. Но я там гонял Rosa Linux, где rpm5 как раз вызывал дичайшую амплификацию, 1 Гигабайт обновлений ставился три часа из-за чрезмерных fdatasync. И кстати перевёл с ZFS на BtrFS и там эта проблема с fdatasync вылезла. На ZFS такое же обновлялось минут пять.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 12:50
	>о я там гонял Rosa Linux, где rpm5 как раз вызывал дичайшую амплификацию, 1 Гигабайт обновлений ставился три часа из-за чрезмерных fdatasync. минутку, с этого места подробнее. у меня alt, причём Сизиф. Там тоже rpm. Время dist-upgrade 1 - 2 гиг пакетов примерно одинаково на xfs и btrfs (причём -o compress=lzo, правда, commit=110) и редко больше 5, ну 15, самое большее, минут.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 14:19
	В Альте rpm4, а не rpm5, и там такой проблемы не было и нет. Если интересно, ищите на форуме той Розы тему rpm4 vs rpm5 (легко находится, а ссылки тут нередко режут). И это проблема не ФС, а rpm5, где кто-то написал кривую работу с БД. В ZFS не проявляется, потому что там оптимизирован fdatasync.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:30
	> БД. В ZFS не проявляется, потому что там оптимизирован fdatasync. 1) Btrfs еще и развивается и оптимизируется. И если что, в свежих ядрах fdatasync ускорили буквально в разы. А бонусом и время монтирования скостили. А заодно и перфоманс операций с дирами улучшили. Люблю такие сюрпризы в новых кернелах. В общем воспринимать btrfs как мировую константу с опытом на древних кернелах - спорная идея. 2) На подобной файлухе при большом апгрейде может иметь смысл сделать снапшот, sync вот этого вот, а потом - нечто типа "eatmydata apt upgrade ..." - при этом вообще sync выпадет из уравнения и если RAM прилично то будет очень резво. А если это не получится, можно откатиться на снапшот (ФС) и попробовать еще раз. Хорошо когда машина времени под рукой. Глупо не пользоваться ее возможностями, пытаясь в лоб натянуть ее на архаичный менеджмент ОС и семантики деланые под классические in-place patching ФС. Более того - снапшот можно и прихранить на несколько дней, посмотреть что все натурально ок. А если не ок - вернуть как было до этого. При том ФС это будет консистентнее чем потуги пакетника это изобразить, там вот именно "работавшая вчера версия ос" хранится. В которой все точно было ЗБС - и при откате это точно будет ЗБС. Во всяком случае, поводов для отвала минимум. Форд про это очень популярно начсет Более Быстрых Лошадей задвинул. Зачем надо более быстрых лошадей, если уже есть автомобили? :)
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 14:21
	Вот первое сообщение той темы, это писал не я (на тот момент у меня была ZFS и не воспроизвелось; в итоге я им и исправил rpm5). Замеры производились на VirtualBox 5.1.26r117224 в Windows 7 x64. Ниже приведу результаты работы стандартных для Mageia и ROSA команд и время их выполнения: --------------------------------------------------------------------------------------------- Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек Поиск "правых" зависимостей пакета: urpmq --whatrequires libgcc1 - Mageia=7 сек - ROSA=1 мин. 48 сек. Поиск "правых" зависимостей пакета: urpmq --whatrequires glibc - Mageia=7 сек - ROSA=5 мин.32 сек. *правые зависимости, т.е. для каких пакетов нужен исследуемый пакет Эти простейшие тесты показали, что RPM5 усредненно в 8-10 раз медленнее, чем RPM4.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	117. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 13:00
	в 2020 купил пару apacer panther нв 256. Один работает до сих пор без нареканий, второй через год перестал показывать ssd-written и ещё через пол-года получил сельнейший и непредсказуемый склероз, в связи с чем ушёл на покой. нагрузка на обоих примерно одинакова, btrfs сжатая, система и часть домашника (из частых записей, только почта), кэши браузеров, всяческие /var/log.../cache вынесены на рам-диск. правда. своп активен. На ещё живом 241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       14742439317 Sector Sizes:     512 bytes logical, 4096 bytes physical То есть, до заявленных 150 tbw далековато. И всё-таки, из двух идентичных, один помер.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	345. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 31-Май-23, 22:46
	> То есть, до заявленных 150 tbw далековато. И всё-таки, из двух идентичных, > один помер. А это вообще вероятностный процесс. Если для вон того чипа заявлено 1000 циклов перезаписи, может с одинаковым успехом как помереть на 10-м цикле, так и 5000 циклов пережить, хоть и не обезали. А заявленные параметры - это "наиболее вероятные", скажем так. А если еще купить нечто поставленное хзкакими каналами - там могут и отбраковку без зазрения совести запаять. Ничего личного, это бизнес.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 10:54
	ну, давно уже не 26, но неприятно, конечно.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	268. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 03:36
	> ext4 с коэф.записи 4 * на коэф.записи 1 для smr_hdd, сравниваем с > btrfs с коэф.записи 26 * на коэф.записи 4 для ssd ~= 100 > т.е. типовой 300-разовый tlc ssd можно будет переписать реально только 3 раза. > Нуачо, хм, "нормальное" такое коммерческое решение. :))) Это для каких нагрузок такое соотношение, интересно? На обычных десктопах и серваках судя по статистике накопителей износ на EXT4 и Btrfs - примерно один фиг, с точностью 20-30%.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	118. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 13:04
	> о том, что BTRFS на жёстких дисках тормозит, и кстати, не тормозит. Только, если возможно, надо бы поставить commit побольше дефолтного, 90 уже ощутимо. И обязательно autodefrag.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	276. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 29-Май-23, 09:36
	> Я о том, что BTRFS > на жёстких дисках тормозит, и поэтому для BTRFS крайне желателны именно > SSD. Не особо тормозит,но балансировка и дефрагментацию при домашнем применение как в старые времена -раз в месяц обязательна :-( Иначе да,начнет тормозить.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	297. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:35
	> Не особо тормозит,но балансировка и дефрагментацию при домашнем применение как в старые > времена -раз в месяц обязательна :-( Иначе да,начнет тормозить. На системном SSD допустим оно вообще не сдалось. Ему на фрагментацию в разумных пределах пофиг. Да и на механических дисках все достаточно культурно, если под завязку пул не забивать. Но вот там если много мелких записей это может уже захотеться. Балансировка вручную вообще нужна только в каких-то очень странных случаях. Когда соотношение данных и метаданных очень радикально изменилось и актуальная аллокация скажем тратит слишком много на block group метаданных. Но это некая очень экзотичная ситуация, при обычном домашнем использовании откуда бы вот это возникнет? Сам по себе block group линейный регион блоков "от сих до сих" и смысл его ворочать просто так - мало. Только чтобы расчистить и отдать место под другой тип хранения (data -> metadata или metadata -> data). Это подразумевает что их соотношение очень радикально изменилось и при вот именно обычном, десктопно-серверном применении это какая-то экзотика.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 09:38
	>Балансировка вручную вообще нужна только в каких-то очень странных случаях. А почистить метаданные ? Не забывайте что мелкие файлы могут писаться  в блок метаданных.Я лучше раз в месяц продефрагментирую и перебалансирую диск,чем потом удивляться где скорость. В Стрекозе -фс хаммерс вообще балансировку забили на каждый день для обслуживания,правда там легче,там снапшотный журнал и просто происходит очистка журнала от мелких снапшотов.
	Ответить | Правка | Наверх | Cообщить модератору

	346. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (346), 31-Май-23, 23:08
	> А почистить метаданные ? Смотря что иметь в виду под очисткой. Обычно под них выделяется 1 или несколько block group, которых потом хватает с энным запасом на рандомные флуктуации. И при обычной работе оно там себе и живет. Если data/metadata ratio радикально не меняется, пустым block groups от метаданных в ощутимом количестве браться не откуда особо. И чтобы та процедура дала измеримый профит, еще постараться надо. Не, если вы когда-то создавали миллионы и миллионы файлов, сильно раздув метаданные, а теперь стерли и больше так не планируете в обозримом будущем, тогда может и иметь какой-то смысл. Но это малость экзотичный сценарий. > Не забывайте что мелкие файлы могут писаться в блок метаданных. Ну да. Однако это реально _мелкие_ файлы (немного менее 4 кило, вообще, конфигуряемо вроде даже). И их количество при типовом использоваини без сильных флуктуаций опять же. Какие-то резкие флуктуации, вот именно мелочи - откуда, опять же? > Я лучше раз в месяц продефрагментирую и перебалансирую диск,чем > потом удивляться где скорость. У меня есть и несколько SSD которые вообще никогда не дефрагались, все равно резво работают, им в разумной степени похрен да и лишние записи дефрагера им не подарок. У сабжа есть опции типа ssd, ssd_spread и discard=async. Для большей части ssd это то что доктор прописал. Можно еще commit=N добавить взяв N побольше (более 300 даст варнинг, это в секундах). Чем реже "точки консистентности", тем меньше записей и они оптимальнее. Но взамен больше свежезаписаных данных будет отброшено при крахе. На механике дефраг разумеется полезен. Насколько именно - зависит от забитости и характера записей. А вот ребаланс - обычно не особо нужен, если не делали чего-то реально странное. Сами по себе чанки блочных групп расположены линейно, при аллокации они обычно не сносятся, и потому они не субъект для фрагментации сами по себе. Если много пустых образовалось, там да, имеет смысл. Но раз в месяц? Ну разве что если там реально хаотичная и активная файлопомойка. > В Стрекозе -фс хаммерс вообще балансировку забили на каждый день для обслуживания, > правда там легче,там снапшотный журнал и просто происходит очистка журнала от > мелких снапшотов. Ну вот у них в деталях я все же не смотрел, юзать бсд мне не импонирует. Но на первый взгляд да, прикольная штука. Однако наездов от юзерей на него ... скажем так, "чаще чем на btrfs", просто самих юзеров мало, однако это как раз и обеспечивает шанс самому по граблям пройтись. Это примерно так: - Если не очень популярная ФС и много воплей, значит там не вытоптали грабли пока еще. Для этого нужна толпа. Потому что разработчики все и вся в сложном дизайне не предусмотрят. - Если популярная ФС и много воплей, это лишь магия количеств. Ну а у btrfs сейчас уже дофига пользователей. Один только фэйсбук поляну слонами вытоптал, напустив миллиард пользователей. Так что если оно у кого-то сыпется, возможно проблема на их стороне а не в коде этой штуки. Вот чего сейчас хватает так это глюкавого железа и юзеров которые не читают системные логи вплоть до момента когда все жестко помрет от bit rot. Тольо тогда уже поздняк.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 01:36
	>Такое ощущение, что все эти xfs, btrfs и прочие – лишь игрушки. Btrfs стабильна и надежна как скала. Скоро в RHEL ее завезут, не зря же ее 2 года тестировали на Федоре. Все, что попадает в Федору, потом переносится в RHEL.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	26. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (3), 27-Май-23, 02:12
	>стабильна и надежна как скала Если компьютер не включать.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от DEF (?), 27-Май-23, 02:26
	Если, как в твоем случае, не включать мозг.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (38), 27-Май-23, 07:33
	Лет через 10
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	52. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от Аноним (52), 27-Май-23, 09:01
	In August 2017, Red Hat announced in the release notes for Red Hat Enterprise Linux (RHEL) 7.4 that it no longer planned to move Btrfs to a fully supported feature (it's been included as a "technology preview" since RHEL 6 beta) noting that it would remain available in the RHEL 7 release series.[30] Btrfs was removed from RHEL 8 in May 2019.[31] RHEL moved from ext4 in RHEL 6 to XFS in RHEL 7.[32] Но, In 2020, Btrfs was selected as the default file system for Fedora 33 for desktop variants.[33] Не могут решить, что-то
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	73. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (73), 27-Май-23, 10:57
	> In August 2017, Red Hat announced in the release notes for Red > Hat Enterprise Linux (RHEL) 7.4 that it no longer planned to > move Btrfs to a fully supported feature (it's been included as > a "technology preview" since RHEL 6 beta) noting that it would > remain available in the RHEL 7 release series.[30] Btrfs was removed > from RHEL 8 in May 2019.[31] RHEL moved from ext4 in > RHEL 6 to XFS in RHEL 7.[32] Правильно, потому что энерпрайзу негоже забавляться с сырой косячной ФС > Но, > In 2020, Btrfs was selected as the default file system for Fedora > 33 for desktop variants.[33] А вот обкатвывать её на дармовых тестерах-хомяках в самый раз. > Не могут решить, что-то Всё логично, и всё уже давно решили. Этот ход RHEL явно говорит о том, что бутерфс не готова для сурьёзного бизнеса.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:15
	>Не могут решить, что-то Все давно решено - Btrfs скоро будет в RHEL. В XFS коровы и чексуммы на данные так и не завезли, Stratis - убогая тормознутая поделка-костыль. Выход только один - Btrfs.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	187. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (187), 27-Май-23, 22:14
	> Все давно решено - Btrfs скоро будет в RHEL. Не будет её в RHEL. Она была в technical preview и не прошла его. Вопрос закрыт.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 28-Май-23, 00:03
	>Вопрос закрыт. Закрытых вопросов в ИТ не бывает.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (187), 28-Май-23, 17:44
	> Закрытых вопросов в ИТ не бывает. Ну, может быть. Когда её снова в превью поместят - вот тогда и порассуждаем не тему "скоро"
	Ответить | Правка | Наверх | Cообщить модератору

	269. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Май-23, 03:42
	> Не будет её в RHEL. Она была в technical preview и не > прошла его. Учитывая что IBM стоял у ее истоков, и IBM пожрал RH - и к тому же btrfs и отбагфиксили, и отоптимизили, как-то вот и без редхата, чего б вон тем с того сливки не снять - кто ж его знает. Ну и сратис vs управление томами btrfs... кхе-кхе, он таки сова на глобусе vs нативные фичи дизайна. Разница соответствует. > Вопрос закрыт. А вы как минимум CTO из IBM тут все такие ушлые собрались?
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	60. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (60), 27-Май-23, 09:57
	у Меня тут выключали свет ежедневно. Половину года... Дак вот btrfs - при пропадании питания вообще проблемы не видит. прблемы у тех кто пытается использовать встроенный raid про который пишут четко в документациях что он НЕ РАБОТАЕТ.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	79. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 11:06
	В таком эксперименте важно, что в момент отказа происходит. Когда читаете Опеннет, данные на диск не пишутся, скорее всего. Интереснее позапускать btrfs balance и defrag и повыдёргивать шнур из розетки.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 12:18
	Я более 1000 раз делал хард-ресет при интенсивной записи в БД - ФС и данные ни разу не скорраптились. Да и тебе уже сказали - свое железо тестируй и кури мануалы. Ну и руки не забудь выпрямить.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 27-Май-23, 14:30
	> Я более 1000 раз делал А я изучал метрологию и понимаю, что эта цифра придумана только что. > Да и тебе уже сказали - свое железо тестируй Ты напрасно говоришь о себе во множественном числе - веса это не придаёт, а показывает слабость позиции. Железо с тех пор работает.
	Ответить | Правка | Наверх | Cообщить модератору

	270. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 03:53
	> А я изучал метрологию и понимаю, что эта цифра придумана только что. Т.е. в возможность создания автотеста файлух вы принципиально не верите, или что? Я не знаю как DEF, но я тоже практикую всякие стресстесты, включая ресеты и слеты питания. В отличие от него я их не считал но величины какого-то такого порядка - бывают. Представляете, лучше уронить железку у себя эн раз и посмотреть не развалится ли, чем это самое случится у кастомера и если это сколь-нибудь массово - вот это будет настоящей ж...й! И вот тут у btrfs так то плюс: fsck вообще нет, так что и интерактив с юзером для починки не требуется. P.s. F2FS кстати на тесте с power loss - разваливается влет. А EXT4 достаточно минимального сбоя чтения и система полностью в дауне. Один несчастный бэд под метаданными или системной либой все выносит в хлам. Такая вот занимательная метрология. > Железо с тех пор работает. Интересно, сколько железа и (стресс) тестов вообще было. Кроме того - вы же понимаете что у железа бывают самые разные приколы? В том числе и "разовые" которые фиг воспроизведешь вот так сразу. Ну вон там транслятор слетел и девайс вообще убился. И вот кто б знал как это воспроизводится? Это даже производитель девайса не знает, иначе починил бы давно. А вот поди ж ты, в какой-то ситуации бывает и вот так. Добро пожаловать в мир глючного железа. Погоня за скоростями привела к хлипкости всего этого. Далеко не любое железо - стабильное и надежное. А чтоб еще и безглючное и предсказуемое...
	Ответить | Правка | Наверх | Cообщить модератору

	310. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 30-Май-23, 08:46
	Я уверен, что DEF ничего не считал, и тесты не проводил. Иначе он бы и написал "какого-то такого порядка", а не 1000.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 31-Май-23, 05:02
	> Я уверен, что DEF ничего не считал, и тесты не проводил. А я немного отличаю этот ник от ноля и по накопленному опыту он вроде в ФС и около разбирается несколько выше среднего по опеннету. И в каких-то вещах пришел к выводам похожим на мои. > Иначе он бы и написал "какого-то такого порядка", а не 1000. Не знаю как он а я мог бы и ровно 1000 циклов влепить. Допустим просто накодив фирмвару МК с таким циклом и посадив его GPIO -> RESET# одноплатника. И получит система 1000 нештатных ресетов, дешево и сердито. На эту тему, моя имха... - Ext4, XFS - "а что вы хотели от фс без full журнала?". Наповал обычно не мрет но консистентность состояний файлов понятно где. В Ext4 полный журнал можно, но скорость будет ацтой из-за двойной записи. CoW появился как воркэраунд этой проблемы ;). - F2FS норовит с позором развалиться. Да так что даже fsck собрать не всегда может. Впрочем в автоматических применениях интересных мне, сама нужда fsck и интерактива - проблема. И это довольно странно для флешовой фс которая так то для околоэмбедовки больше. Даже в смарте показывать хомяку fsck - малоперспективно, имхо. - Btrfs хз, ни разу таким методом не убился, ему ребуты вообще довольно похрен и fsck при этом не надо, cow при этом как максимум потеряет некие свежие записи. У них это и на данные и на метаданные распостраняется и чего б ему при этом дохнуть - кто б его знает. - JFS - хз, не тестировал особо. Он медленный и печальный, на него все уже забили. - Рейзер3 разносит тома fsck'ом и это у них "known issue", даже описаны варианты как этот issue вызвать. Это делает их fsck крайне стремным тулом. А других рейзеров вообще в майнлайне нет, для меня это showstopper.
	Ответить | Правка | Наверх | Cообщить модератору

	337. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 31-Май-23, 15:48
	>> Я уверен, что DEF ничего не считал, и тесты не проводил. > А я немного отличаю этот ник от ноля и по накопленному опыту > он вроде в ФС и около разбирается несколько выше среднего по > опеннету. И в каких-то вещах пришел к выводам похожим на мои. Потому что он где-то что-то прочёл и эту инфу разносит. Инфа необязательно неверна, но это банальная вера, а не знания, полученные в результате опыта. >> Иначе он бы и написал "какого-то такого порядка", а не 1000. > Не знаю как он а я мог бы и ровно 1000 циклов > влепить. Допустим просто накодив фирмвару МК с таким циклом и посадив > его GPIO -> RESET# одноплатника. И получит система 1000 нештатных ресетов, > дешево и сердито. "Ровно 1000 циклов". А не "более 1000 раз". Ну то есть, откуда он знает, что более 1000? Считал? И как он столько насчитал?) Когда погрешность всегда плюс-минус.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:17
	Не работают только parity-raid'ы, а mirror-raid'ы - работают.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	304. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 03:38
	> Не работают только parity-raid'ы, а mirror-raid'ы - работают. Более того, поскольку там у метаданных и данных могут быть разные схемы хранения, ничему не противоречит метаданные как RAID1(может даже C3) а данные как RAID 5 или 6 - и вот такое комбо даже не страдает write hole'ом. А т.к. основной объем обычно данные, то эффективность по использованию места более-менее как у RAID5/6. Это сами разработчики такой финт придумали. Вроде реально работает, так сразу не разваливается.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Отражение луны (ok), 27-Май-23, 10:34
	Живу на btrfs, все работает отлично. Что я делаю не так?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	99. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Да (?), 27-Май-23, 11:43
	Сидел на btrfs, все покорраптилось. Постоянно проблемы у разных компаний и людей с ней. Что с ней не так ? Сижу на XFS все работает как часы.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Отражение луны (ok), 27-Май-23, 11:45
	> Сидел на btrfs, все покорраптилось. Постоянно проблемы у разных компаний и людей > с ней. Что с ней не так ? > Сижу на XFS все работает как часы. Насколько давно это было?
	Ответить | Правка | Наверх | Cообщить модератору

	271. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 03:55
	Я бы спросил - с какими ядрами? Использовать какой-нибудь 2.6.32 можно и в 2023 году. При этом разумеется получится горя хлебнуть если btrfs тех времен взять. И нет, никто не будет бэкпортить фиксы файлух в древние ядра в общем случае.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Getfor (?), 27-Май-23, 11:25
	Ничего, что XFS не новомодная игрушка, а достаточно пожилая файловая система причем одна из максимально стабильных?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	113. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 12:38
	Критерии стабильности в студию.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от пох. (?), 27-Май-23, 14:48
	крэшится очень стабильно - с 2009го года наблюдаю. Но это на bare metal. На виртуалках когда с дисками разговаривает кто-то поумнее - все хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (149), 27-Май-23, 16:30
	riser5 же, ну...
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	176. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (176), 27-Май-23, 20:23
	Если только самому собирать kernel и добовлять пач чтобы работал riser5, а это вариант не для всех. И то это, чтобы попробовать и решить riser5 усраивает или нет.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (176), 27-Май-23, 20:53
	кстати пусть разработчик 5 версии подарит нашему невте газ прому файловую систему, пусть сами её пилят, может назовут рашен фидерашен файловая система тогда может и взлетит, но есть вариант. что заберут использовать будут. а наработки открывать не будут и она 5 версия останется внутри этих корпораций.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	180. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (176), 27-Май-23, 20:55
	или ещё кому, зелёный есть.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (176), 27-Май-23, 20:57
	или продать. наверно уже бы продал еслибы был спрос.
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	211. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 28-Май-23, 08:13
	> кстати пусть разработчик 5 версии подарит нашему невте газ прому файловую систему, > пусть сами её пилят Как бы у нефтегазпрома и так имущества больше, чем у разработчика-энтузиаста, кто уже и так вложил в проект немало знаний и времени. Почему любитель всеобщего счастья не предложил им профинансировать разработку, что бы автор мог нанять ещё кодеров? Это влияние идеек СПО?
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	288. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 17:54
	"или продать. наверно уже бы продал если бы был спрос" Я это всё писал в основном не с точки зрения как заработать, а как сделать чтобы этой файловой системе дать спрос, чтобы ей пользовались. А так файловая система есть, но самому собирать kernel не для меня и масс, не вариант, не хотят так делать когда есть выбор сделать проще.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 30-Май-23, 08:55
	Про "продать" появилось только в третьем сообщении. Дело тут не в спросе. Нефтегаз, как и вся добыча и торговля ресурсами, это консервативный бизнес. Такие люди 1000 лет делают одно и тоже (дрова лишь заменили на нефть) и не лезут не в своё дело. Они полагают, что остальные точно такие же профессионалы и покупают ПО у "айтишников". Последним не выгодно создавать спрос, куда выгоднее взять бесплатно.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (176), 27-Май-23, 20:18
	Ext2 и jfs я не шучу?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	177. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (176), 27-Май-23, 20:39
	на всякий случай jfs2, а так их две версии jfs1 и jfs2. jfs2 обозначают как jfs. вроде так. "В операционной системе AIX существует два поколения JFS, называемых JFS (JFS1) и JFS2 соответственно. В других операционных системах, таких как OS/2 и Linux, существует только второе поколение, которое называется просто JFS. Также JFS называют файловую систему VxFS компании Veritas Software, используемую в ОС HP-UX"
	Ответить | Правка | Наверх | Cообщить модератору

	290. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Май-23, 00:10
	Не точно написано. Надо так. Ext2 и jfs? Я не шучу.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	227. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Андрей (??), 28-Май-23, 14:18
	Пользуюсь btrfs как основной для корня уже около 4х лет, работает без проблем. Может всё зависит от прямых рук?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	289. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 29-Май-23, 18:27
	Но, может быть так: видимых проблем нет, а проверяя на ошибки раздел диска проверка выявляет ошибку или ошибки и не исправляет. И появляется вопрос, что с этим делать? Или не чего не делать?
	Ответить | Правка | Наверх | Cообщить модератору

	340. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 31-Май-23, 20:24
	> Но, может быть так: видимых проблем нет, а проверяя на ошибки раздел > диска проверка выявляет ошибку или ошибки и не исправляет. И появляется > вопрос, что с этим делать? Или не чего не делать? В этом случае нехило бы указать как минимум сообщение об ошибке. При том желательно - сразу разработчикам. Ну и заодно нехило бы проверить что железо работает корректно, поскольку в современных кернелах фс разваливаются редко. Вон то - очень неприятное исключение, и так то неплохая оплеуха "качеству" редхатов и прочих LTS vs блочный уровень/фс.
	Ответить | Правка | Наверх | Cообщить модератору

7. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
Сообщение от Аноним (7), 27-Май-23, 00:05
Ошибка в багзилле шляпы. Возможно, напатчили лишнего эти шляпники
Ответить | Правка | Наверх | Cообщить модератору

	10. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от birdie (ok), 27-Май-23, 00:28
	Количество собственных патчей в Fedora сведено к абсолютному минимуму за последние 20 лет. Вы слегка отстали от жизни. Да, лет 20 назад их было море, но тогда не было git, и разработка была на порядок медленней. Таскать море патчей и портировать на новое ядро каждый раз - дорого. Лучше послать в upstream. https://src.fedoraproject.org/rpms/kernel/tree/f38
	Ответить | Правка | Наверх | Cообщить модератору

	12. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от Аноним (7), 27-Май-23, 00:32
	Сведено, но далеко не нулевое, патчей много все равно. И не факт, что проблема не в одном из них. Посмотрим, до чего дойдут в разборке в багзилле ) А с навешиванием ярлыков завязывайте )
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от birdie (ok), 27-Май-23, 00:42
	Я не понял при чём тут "ярлыки". Навешивал их тот, кто обвинял априори Fedora в кривых патчах выше. > напатчили лишнего эти шляпники Последние ошибки с ядром Fedora, которые у меня были за последние лет 10, все так же были в mainline ядре. Если вы хотите отвечать за базар, что де "Fedora патчит и от этого жуткие проблемы" - прошу продемонстрировать конкретные bug reports в RedHat Bugzilla. Она публична, там кроме спама ничего не удаляют. > Сведено, но далеко не нулевое, патчей много все равно. Красиво лгать не запретишь: Ядро kernel-6.2.15-300.fc38.src.rpm $ ls -l | grep -E -i "patch|diff" -rw-r--r--. 1 root root         0 May 11 00:00 linux-kernel-test.patch (пустой файл) -rw-r--r--. 1 root root     84797 May 11 00:00 patch-6.2-redhat.patch -rw-r--r--. 1 root root     14414 May 11 00:00 Patchlist.changelog (не патч) -rw-r--r--. 1 root root      1176 May 11 00:00 rhelkpatch1.x509 (не патч) Один патч на 85KB. Описание здесь: https://src.fedoraproject.org/rpms/kernel/blob/f38/f/Patchli... Ничего, что касается VM, IO или драйверов RAID/ATA, кроме нескольких патчей NVMe из upstream. У людей с проблемами не NVMe. Есть патч для XFS, но он уже включен в 6.4-rc3, где проблема не наблюдается: https://lkml.kernel.org/linux-xfs/20230412214034.GL3223426&#.../ Ждём расследования. Вдруг я окажусь не прав, lol.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от n00by (ok), 27-Май-23, 06:52
	> Я не понял при чём тут "ярлыки". Навешивал их тот, кто обвинял > априори Fedora в кривых патчах выше. >> напатчили лишнего эти шляпники Главное, при цитировании вырезать "возможно", тогда цитата будет действительно похожа на обвинение. Кто не читал или забыл исходное сообщение, поддержит мастера риторики. Один вопрос - с какой конкретно целью это сделано?
	Ответить | Правка | Наверх | Cообщить модератору

	224. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от birdie (ok), 28-Май-23, 12:57
	Расследование закончилось - ошибка в самом ядре, патч уже есть. Патчи Fedora, как я и предполагал, ни при чём.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	244. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (244), 28-Май-23, 18:26
	"Ошибка в самам ядре" самостоятельно материализовалась? Или, может быть, ее туда шляпники-то и занесли? ))
	Ответить | Правка | Наверх | Cообщить модератору

	247. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (244), 28-Май-23, 18:39
	Смотри, кто автор бажного патча: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	249. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 19:23
	RedHat - один из основных разрабов ядра, systemd, glibc, gnome, gtk и wayland. Что вы этим хотели сказать? Патч для mainline, а не для конкретно ядра Fedora. Проблема коснулась и пользователей debian в т.ч.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (244), 28-Май-23, 22:16
	в том и дело ) подгадили не только себе, но и всем вообще )
	Ответить | Правка | Наверх | Cообщить модератору

	256. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (256), 28-Май-23, 22:51
	> в том и дело ) подгадили не только себе, но и всем > вообще ) Только анонимы в рунете могут даже предположить, что сотрудники redhat гадят. Я не знаю сколько вам лет, но если больше 12, то мне от этого комментария просто противно стало. До сблева. Это не шутка, это просто низость.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (244), 28-Май-23, 22:26
	Не имеет значения, где именно разместили бажный патч, не протестировав как следует. Локально в федоре или запостили в ветку ядра (что хуже на порядок). Авторство от этого не изменяется - это шляпники. Поэтому вы были не правы, а тот аноним, которого вы изволили назвать лжецом, прав (вернее, угадал). Проблема в патчах шляпников
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	281. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (256), 29-Май-23, 11:01
	> Не имеет значения, где именно разместили бажный патч, не протестировав как следует. > Локально в федоре или запостили в ветку ядра (что хуже на > порядок). Авторство от этого не изменяется - это шляпники. Поэтому вы > были не правы, а тот аноним, которого вы изволили назвать лжецом, > прав (вернее, угадал). Проблема в патчах шляпников Аноним заявил, что 1) Ядро в Федоре жутко патченное - ложь, фиксов там минимум, большинство взяты из будущего rc 2) Проблема из-за именно патчей в Федоре - снова ложь Вам лично: RedHat  - основной разработчик Linux. Если у вас с этим проблемы, исчезнете из линукса и этого обсуждения. Вам лично: патч, который вылился в регрессию, решал проблему, но в нем была ошибка. Вам лично: протестировать было сложно, ибо стандартные тесты не учитывали редкую и необычную ситуацию. От анонимов на opennet крайне противное чувство. Шутки и предположения уровня клинических uдuoтов: "redhat специально всем подгадила". Ха-ха, смешно. Убожество. Максим: слово uдuoт - это не мат. Это термин из психиатрии, который обозначает уровень интеллекта.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:41
	> RedHat - один из основных разрабов ядра, systemd, glibc, gnome, gtk и wayland. А вот известные разработчики блочного уровня и ФС оттуда почему-то слиняли. Так, исторически. Кто б его знает почему. Последним из грандов на виду оттуда Bacik смылся. Зато пришел btrfs окультуривать почему-то. И его присутствие - "ощущается". Свежим взглядом он пришиб несколько "привычных" проблем и я так понимаю что часть оптимизаций по его линии как раз.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	212. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (7), 28-Май-23, 08:31
	От места размещения бажного патча результат не меняется. Кто автор изменений, которые привели к этой ситуации? Не шляпники ли? При этом, проблема приехала всем из-за размещения патча не локально без всестороннего тестирования
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	32. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от dalco (ok), 27-Май-23, 04:05
	Если верить Phoronix'у, то проблема с xfs наблюдается и на Debian при использовании ядра 6.3.x. Так что, получается, не шляпники виноваты.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	213. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (7), 28-Май-23, 08:38
	Виноваты авторы тех изменений в ядре, что привели к этой ситуации. И это, вероятно, шляпники, так как они очень активно патчат xfs
	Ответить | Правка | Наверх | Cообщить модератору

	242. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 28-Май-23, 18:01
	Потому что ты не умеешь кодить. Приходится делать это кому-то другому.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (244), 28-Май-23, 18:27
	К чему это тут? Если сам не умеешь, не думай, что остальные такие же )))
	Ответить | Правка | Наверх | Cообщить модератору

46. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–3 +/–
Сообщение от Аноним (47), 27-Май-23, 08:13
xfs зло,файлы с недокаченого торрента исчезали когда пользовался ей в позапрошлом году и сохранки. С btrfs такого уг вообще не наблюдаю.
Ответить | Правка | Наверх | Cообщить модератору

	61. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (60), 27-Май-23, 10:01
	Btrfs этот то единственное чтоне дает мне поставить RHEL на комп. У меня на ней все. От дисков до флешек. А шляпа решила что она вжух и небудет собирать ядро с поддержкой одной из фс. вообще... гении.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от keydon (ok), 27-Май-23, 10:20
	Ну так сам собери
	Ответить | Правка | Наверх | Cообщить модератору

	84. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:12
	Ставь Федору - там btrfs по-умолчанию. Через пару лет и в RHEL станет также, как бы хомячье не выло о ее мнимой нестабильности.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	192. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Kuromi (ok), 27-Май-23, 23:10
	Шапка от BTRFS отказалась и вовсю патчит XFS (наверняка баги оттуда же), уже даже COW добавили которого изначально не было. Комбинируя  сдругими компонентами у них полчается некий кастомный аналог BTRFS\ZFS. Откажутся ли? Кто знает...
	Ответить | Правка | Наверх | Cообщить модератору

	300. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:42
	> Шапка от BTRFS отказалась и вовсю патчит XFS (наверняка баги оттуда же), > уже даже COW добавили которого изначально не было. Комбинируя  сдругими > компонентами у них полчается некий кастомный аналог BTRFS\ZFS. > Откажутся ли? Кто знает... Если попробовать сратис и btrfs device add/remove... ну... ты понял :)))
	Ответить | Правка | Наверх | Cообщить модератору

	320. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от DEF (?), 30-Май-23, 21:28
	>уже даже COW добавили которого изначально не было Никакого COW в XFS не добавлено и не добавят. Поддержка коров требует поломку обратной совместимости в on-disk формате. Легче просто использовать btrfs.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	323. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от Kuromi (ok), 30-Май-23, 22:40
	>>уже даже COW добавили которого изначально не было > Никакого COW в XFS не добавлено и не добавят. Поддержка коров требует > поломку обратной совместимости в on-disk формате. Легче просто использовать btrfs. Разве там уже не чуть ли пятая версия формата данных на диске?
	Ответить | Правка | Наверх | Cообщить модератору

	188. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Tron is Whistling (?), 27-Май-23, 22:31
	OEL/UEK поставь, там ффсё есть.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	76. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 11:02
	> fs зло,файлы с недокаченого торрента исчезали исчезали -- это как? что конкретно происходило? >  С btrfs такого уг вообще не наблюдаю держать файлы типа торрентов на btrfs с невыключенным cow, так себе идея. Нет, ФС не развалится (скорее всего), эту десткую болезнь вылечили. Но вот в один прекрасный момент работа с некими файлами (неважно, торрентами, vm или бд -- суть одна, когда файл очень часто и быстро меняется) станет.. странной, от этого не уйти. И лечение тут только одно, полностью перезаписать файл с нуля.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	161. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (47), 27-Май-23, 17:43
	Если например xmonad закрыть по shift+alt+q во время скачивания торрента,то несмотря на то,что там было уже за 90% на разделе с xfs файлов потом нет и надо после запуска Transmission скачивать заново. Также если игра вылетает,то потом исчезают созхранки. На btrfs такого не замечаю.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (47), 27-Май-23, 17:50
	Комп вроде потом тоже выключал. В общем с торрентами так было несколько раз и я забил на xfs. Ядро старое 4.9 было.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от gleb (?), 27-Май-23, 19:42
	не воспроизводится. 4.9.38 4.14.55 5.4.91 5.10.66 5.15.87
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	172. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (47), 27-Май-23, 20:08
	Ядро точно 4.9 было.я его долго юзал. Когда дропнули  поддержку тогда только перестал.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (47), 27-Май-23, 20:21
	+ RT патчи.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 28-Май-23, 06:57
	ну вот я проверил на 5и разных ядрах. проблемы не вижу.
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	215. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (47), 28-Май-23, 09:23
	Рад за ваш успех,мне так не повезло. Теперь считаю xfs какашкой. btrfs норм. Если бы не решили дропнуть reiserfs,то использовал бы ее.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от gleb (?), 28-Май-23, 09:31
	Дело в том, что ни Ваше, ни моё мнение, по большому счёту, ничего не решает и никого не интересует. А вот объективные результаты работы, таки, да. ext по скорострельности в реальных условиях и надёжности, сливают xfs. Можно сколько угодно говорить, что "мне не повезло", факт от этого не изменится. Поэтому, не повезло -- ну ок. Миллиону других -- повезло. Ну и ладненько. А вот нежеление разобраться, что же именно пошло не так и простая замена шила на мыло, может и сработает "здесь и сейчас", но никто не рискнёт сказать, что же будет с течением времени.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (47), 28-Май-23, 09:53
	На убогую ext* мне вообще плевать. Я пробовал их все и имею свое мнение о них. Мой выбор btrfs,а что вы или кто-то другой выбрал мне до лампочки. Не сумели воспроизвести косяк про который я тут написал - такой вот вы тестер. Вы наверное админус и приняли решение на серверах юзать убогую xfs - вам и страдать.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (239), 28-Май-23, 17:47
	> держать файлы типа торрентов на btrfs с невыключенным cow, так себе идея. > торрентами ... файл очень часто и быстро меняется А разве файлы, скачанные с торрентов часто и быстро меняются? Допустим файлы качаются кусками по 4МБ, такими же кусками и записываются на файловую систему. Вот один раз записались данные, и потом не меняются, да ещё и каждый 4МБ-блок контрольной суммой в торенте заверен. Я наверное что-то упускаю, объясните пожалуйста что там где меняется? > И лечение тут только одно, полностью перезаписать файл с нуля. Но файл же и во время скачки пишется с нуля до своего полного объёма?
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	286. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 29-Май-23, 14:50
	> А разве файлы, скачанные с торрентов часто и быстро меняются? они пишутся в произвольные места, обычно, разряжённого файла. на btrfs каждое изменение файла == увеличение поколения сабвольюма, в котором этот файл находится. > Но файл же и во время скачки пишется с нуля до своего полного объёма? в том и суть торрентов, что нет. Пишется произвольными блоками в произвольные места файла.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (239), 30-Май-23, 02:40
	>> А разве файлы, скачанные с торрентов часто и быстро меняются? > они пишутся в произвольные места, обычно, разряжённого файла. на btrfs каждое изменение > файла == увеличение поколения сабвольюма, в котором этот файл находится. >> Но файл же и во время скачки пишется с нуля до своего полного объёма? > в том и суть торрентов, что нет. Пишется произвольными блоками в произвольные > места файла. А если преаллоцировать место или скачивать последовательно, это решит проблему?
	Ответить | Правка | Наверх | Cообщить модератору

	312. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 30-Май-23, 08:59
	достаточно отключить cow для этих файлов и/или папок. но производительность всё равно будет немного меньше, чем на xfs, например.
	Ответить | Правка | Наверх | Cообщить модератору

	313. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 30-Май-23, 09:02
	и да, торрент-качалки обычно и так заранее выделеяют место, создавая разрежённый файл. и нет, этого недостаточно, поскольку при включенном cow запись всегда происходит в новое место. но проблема со странным поведением, начиная с некоторого числа перезаписей, не от этого, а (моя гипотеза) от быстрого увеличения номера поколений и безудержного разрастания дерева.
	Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

50. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
Сообщение от Аноним (50), 27-Май-23, 08:38
XFS как раньше затирал файлы, так и сейчас продолжает, стабильность ага. Вот думаю попробовать btrfs, но там тоже проблем хватает. Забитый диск, когда точно знаешь, что это не так убивает все желание попробовать эту фс на корню. Похоже так и придется сидеть на старой доброй ext4, то же зло, но стабильное и без сюрпризов.
Ответить | Правка | Наверх | Cообщить модератору

	74. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 10:57
	>XFS как раньше затирал файлы можно продемонстрировать? повторюсь, у меня с 2002 г. активно юзается в 4 разных местах и дома. Не наблюдается.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (324), 31-Май-23, 01:47
	Попробуйте его с ceph'ом поиспользовать (да, я знаю что официально не рекомендуется, собственно поэтому и не рекомендуется), скажем под ежедневные бекапы.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 31-Май-23, 16:56
	так проблема-то, чья?
	Ответить | Правка | Наверх | Cообщить модератору

	100. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:43
	>Вот думаю попробовать btrfs, но там тоже проблем хватает И какие же там проблемы?
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

55. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
Сообщение от Аноним (55), 27-Май-23, 09:07
Не знаю что там про надёжность и стабильность xfs и работу с большими объёмами. Но сколько раз не пробовал её использовать, приходилось отказываться. Самый первый раз 7-8 лет назад. Развернул чистый Oracle Linux 7.1 на xfs. ФС развалилась при установке обновления, заодно превратив в фарш все разделы. Ладно, в прошлом году снова решил попробовать, думаю должна быть стабильна. Сервер Proxmox Backup Server 7.2 (Debian 11) с аппаратным RAID 10 c батарейкой на HDD корпоративного класса. Нарезал раздел на LVM под данные 16Тб и развернул xfs с настройками по дефолту. Всё работало нормально до момента пока данными не заняло 90% раздела через месяц. После этого ошибки фс, повреждения данных. Два раза получилось восстановить ФС штатной утилитой. На третий уже ничего не помогло, ФС с ошибками, они не чинятся. Данные в фарш. Офигенная ФС, чё сказать, 15Тб резервных копий в небытие. Снёс, поставил ext4, она просто работает и пофиг ей на всё, уже год без нареканий. Пережила уже пару отключений света.
Ответить | Правка | Наверх | Cообщить модератору

	77. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 11:04
	в фарш? все разделы? и потом постепенно нарастающие ошибки? а тут точно xfs виновата? боюсь, с ext4 будет не менее непиятный сюрприз.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (183), 27-Май-23, 21:12
	После этого переразвернул сервер на ext4. 8 лет, до сих пор работает. Весь регион на него отчётность сдаёт.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (203), 28-Май-23, 01:50
	Это разные анонимы пишут. И да, 8 лет назад proxmox backup server не было.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (183), 28-Май-23, 11:35
	В данном случае речь шла про Oracle Linux 7.1. И речь там больше про то что после установки чистой ОС на xfs при обновлении ОС все ФС рассыпались (из-за того что пакет с xfs обновился). И никто не сможет гарантировать что обновлении такого повторно не случится. При это переразвёрнутая ОС на этой же ВМ на ext4 просто работает, обновляется и не морочит голову. Нагрузочные тесты, проверки и прочее тоже проблем не выявили. Поэтому выбор очевиден, раз ext4 стабильно работает и не морочит голову, то плевать я хотел на достоинства xfs, если она нестабильна. Сервер Заказчику сдан, работает и никому мозг не делает уже 8 лет.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 28-Май-23, 06:55
	не очевидно, что это не аргумент? надо разбираться и тестировать. в противном случае не исключено, что оно взорвётся в непредсказуемый момент времени и с учётом "всего региона", надёжно похоронит автора. в самом деле, в миллионах случаев ни у кого ничего в "фарш" не превращается, а тут вдруг...
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	221. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (183), 28-Май-23, 11:40
	Вот прямо сейчас ядро 6.3.3 превращает в фарш разделы с xfs. Это факт. За ext4 такого не замечено. Думаю конечно не миллионы случаев, но совершенно неприятно. Мне видится что это аргумент и что xfs ещё требует доводки до стабильного состояния.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:41
	XFS не журналит данные, только метаданные. Поэтому ее лучше юзать для файлопомоек, которые не жалко обнулять. Для важных и ценных данных - только Btrfs с современными крнелами, а не с протухшей пропатченной дрянью, как в RHEL.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	173. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от thhh (?), 27-Май-23, 20:18
	Эта "протухшая пропатченная дрянь" и есть бэкпорты всего нового с "современных кернелов"
	Ответить | Правка | Наверх | Cообщить модератору

	198. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 28-Май-23, 00:06
	По какой-то неведомой причине эти бэкпорты глючные и менее стабильные, чем свежие апстрим-кернелы. Разрабы btrfs рекомендуют юзать ее со свежими ядрами не просто так.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (47), 28-Май-23, 09:26
	На 4.19 прекрасно себя чухает. Нет проблем,проста и надежна.
	Ответить | Правка | Наверх | Cообщить модератору

64. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
Сообщение от beck (??), 27-Май-23, 10:31
Прочитал обсуждение. Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо. Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то, и другое. Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система,  которая просто работает? Как например NTFS?
Ответить | Правка | Наверх | Cообщить модератору

	80. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+4 +/–
	Сообщение от Аноним (73), 27-Май-23, 11:06
	> Прочитал обсуждение. > Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо. > Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то, > и другое. > Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система, >  которая просто работает? Как например NTFS? Да, EXT4 стабильнее всех работает, а те кто про неё пишут гадости, подсосы бутерфс от красношляпы либо просто полезные идиоты, либо на зряплате. А ты вообще жирный MS-тролль, так-то.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 27-Май-23, 11:09
	>подсосы бутерфс от красношляпы Сосайтник, бутерфс от оракла.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (109), 27-Май-23, 12:30
	Ой извините подсосы бутерфс от оракцле.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 27-Май-23, 11:08
	>Как например NTFS? Вот это рили дерьмо. >а под линукс есть хоть одна нормальная файловая система Конечно есть - Btrfs.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	83. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от n00by (ok), 27-Май-23, 11:10
	На zfs не каждый местный эксперт сможет установить систему, так что это их экспертное мнение скопировано у других таких же экспертов. Вероятно, в случае остальных ФС экспертиза проводится точно так же.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	86. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Читатель сайта (?), 27-Май-23, 11:15
	Сейчас придут и расскажут и почему NTFS тоже дерьмо. :) А IMHO - вся беда в том, что серебряной пули так и не сделали. Каждая из этих FS хороша для употребления в своих условиях. Но это ж думать надо...
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	102. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 11:52
	> etx4 - дерьмо Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов. Более надёжной ФС в Линукс нет и не было. Самый большой косяк - не умеет делать дефрагментацию свободного места, но с приходом SSD проблема перестала быть актуальной. Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	105. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от DEF (?), 27-Май-23, 11:58
	>Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов. И чо? У одного только Фейсбука, btrfs юзается в хвост и в гриву на более миллиона серверов. >Более надёжной ФС в Линукс нет и не было. Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори. >Вторая по надёжности, я не шучу, vfat, но она не подходит для хранения файлов Linux. Укатайка...
	Ответить | Правка | Наверх | Cообщить модератору

	114. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 12:39
	> Ложь. ФС, которая не умеет чексумить данные - не может быть надежной априори. Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum. Проблема не настолько серьёзная, чтобы говорить, что без этого ФС не ФС. Я бы назвал data checksum nice to have фичей, но никак не crucial/essential.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от DEF (?), 27-Май-23, 13:45
	>Есть решения без этого, начиная от dm-integrity, заканчивая тупо md5sum. Это не решения, а днищенские костыли. Гарантия целостности данных должна обеспечиваться на уровне ФС.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 27-Май-23, 13:58
	> Это не решения, а днищенские костыли. Кто это решил? Я использую файлы с checksums более 20 лет. Проблем не было. Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет? FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS). Приехали? Я скажу ещё более страшную вешь - checksumming без recovery бесполезен буквально полностью. Всё, отдыхайте. А вот тут решений на уровне FS я не знаю вообще. Есть PAR2, но это бесконечный геморрой, который я заменил на RAR. > должна обеспечиваться на уровне ФС Кто кому должен? Почему должен? Я сейчас скажу, что вы мне должны $1M, потому что так "правильно". Всё? Приехали? Не надо свои хотелки превращать в status quo.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от пох. (?), 28-Май-23, 00:20
	> Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. > Чем вам это поможет? копий данных на современных fs может быть, внезапно, не одна. И даже носителей тоже может быть не один. > FS вам выдаст пустой блок вместо данных (кажется, это так сейчас работает в ZFS). когда кажется - помогает креститься. zfs (как и любая другая с контролем целостности) ничего не выдаст, вернет ошибку чтения, если не имеет второй копии. И ты хотя бы узнаешь что файл поврежден (возможно копии нет у fs, а ты был умный и у тебя она есть где-то еще). Если копия есть и валидна - молча вернется правильный блок, а битый при scrub будет перезаписан, без необходимости тебе лично участвовать в этом процессе. Раз ты даже этого не знаешь - чего стоит твоя "экспертиза"?
	Ответить | Правка | Наверх | Cообщить модератору

	219. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–3 +/–
	Сообщение от Sw00p aka Jerom (?), 28-Май-23, 10:34
	>копий данных на современных fs может быть, внезапно, не одна. И какой копии доверять? Как доказать целостность? Где гарантии, что копии целые? Человек до сих пор не придумал этого механизма.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Прохожий (??), 29-Май-23, 11:01
	Тебе ж написали:контрольные суммы.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 29-Май-23, 11:36
	> Тебе ж написали:контрольные суммы. а где храним эти контрольные суммы? и в каком количестве?
	Ответить | Правка | Наверх | Cообщить модератору

	202. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от DEF (?), 28-Май-23, 00:52
	>Кто это решил? Это решили логика и здравый смысл. >Я использую файлы с checksums более 20 лет. Проблем не было. Никого не интересует твой опыт использования костылей. >Кроме этого, OK, у вас есть data checksumming на уровне FS, данные на носителе похерились по разным причинам. Чем вам это поможет? Я запущу scrub. Если у меня зеркальный RAID, то Btrfs автоматически восстановит поврежденные данные и метаданные из уцелевшей копии. Если у меня сингл, то ФС как минимум сообщит мне, какие блоки поврежденны и на каких файлах. И я как минимум не допущу попадания битых файлов в новый бэкап и восстановлю их из старого бэкапа. >Кто кому должен? Почему должен? За целостность данных в реляционной БД отвечает именно БД, а не какие-то костыли за пределами БД. Точно также и с ФС. ФС для этого и создана, чтобы обеспечивать целостность данных. Это ее прямая зона ответственности.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	223. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 12:56
	*ля, стыдно всё это читать. Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums? Или вы реально думаете, что домашние пользователи все побежали делать RAID и хранить копии данных в трёх географических разделённых местах? У вас г*вно в голове, уважаемый - вы считаете априори, что 1) Все данные - это безумно важно! 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае атомной зимы! Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно. Вы так бы и начали: "вот я работаю там и там, у нас такие критерии, нам только ZFS подходит". Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING". *ля. Ржу. Корона не жмёт?
	Ответить | Правка | Наверх | Cообщить модератору

	237. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от dasd (?), 28-Май-23, 17:34
	>Если у вас есть RAID, куча копий данных, да на кой хрен вам вообще checksums? Начните уже думать, а не только троллить. RAID защищает немножко от другого. Куча копий данных - как выбрать верную? (Битовые ошибки - существуют)
	Ответить | Правка | Наверх | Cообщить модератору

	317. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 30-Май-23, 17:10
	Мда. С тобой все ясно. Таблетки не забывай принимать вовремя, которые тебе назначил твой лечащий психиатр.
	Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

	191. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Kuromi (ok), 27-Май-23, 23:07
	Именно поэтому Гугль потихоньку переводит Андроид на f2fs для RW (хотя тут неточно) и EROFS для RO (вот тут уже решение принято).
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	327. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (324), 31-Май-23, 01:59
	> Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов. Математика не нужна. Миллионы школьников не могут ошибаться.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	106. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от ptr (??), 27-Май-23, 12:06
	При форматировании флешки или внешнего HDD в NTFS проблемы с потерями данных я встречал намного чаще, чем при форматировании их в ext4. Само собой, почти все проблемы возникали после выдергивания на горячую. И если на NTFS умирали целые директории, то на ext4 - лишь записанные непосредствено перед выдергиванием файлы. Когда в мае 2005 года в ряде ЦОД сервера аварийно отрубали во избежании перегрева (в тот день было жарко и солнечно), ext3 проблем при включении серверов не доставляло, чего не скажешь об NTFS. xfs - для десктопа или ноута не лучший выбор. А вот для дисков многотерабайтной БД - самое то. Особенно если эта БД сама контрольные суммы страниц считает. ext4 - наборот, когда не нужны многотерабайтные диски для БД. btrfs - претендует на универсальность, но, на практике, проигрывает в производительности xfs, если диск используется для БД. Проверяли на PostgreSQL с выключенным CoW. С включенным - вообще молчу. zfs - навороченный комбайн. Но на практике то нужна производительность и надежность, а не 100500 фич.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	110. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (109), 27-Май-23, 12:33
	NTFS игрушечная ФС.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (8), 27-Май-23, 21:53
	NTFS просто старенькая и глючная, слишком много напихали поэтому регулярно находятся 1000 способов её развалить. Адово фрагментируется и деградирует, плоховато скалируется, например, видно, когда используешь какой-нибудь msys2 и линуксовый софт в нём, эта куча мелких файлов весьма плохо работает по сравнению с линуксом. Да и вообще адок с вендософтом тоже, особенно, как туда моно с метро запихали. Отключаешь суперфетч и наслаждаешься. Поэтому, файлы приложения должны быть упакованы в большие архивы и подгружаться стримингом ресурсов, а не лежать на диске. Но, в целом, использовать можно, просто не серверная ФС. А игрушечная ФС, это у Эпла. SSD конечно многие проблемы нивелирует в значительной мере.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 13:01
	Практически всё в этом ответе - наглая ложь, и непонимание работы: "куча мелких файлов весьма плохо работает". По поводу: "1000 способов её развалит" - дикая ложь. Ради прикола во время распаковки тысяч мелких файлов делал reset 15 раз подряд, ни разу не делая chkdsk - забавно, но всё работало. Единственное в тему - это фрагментация, но это перестало быть важным во времена SSD.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (8), 28-Май-23, 13:28
	Хорошо, давай вместо твоего пустословия я приведу самый надёжный способ её уничтожить, который работал на протяжении многих лет. Включаешь сжатие какого-нибудь бесполезного каталога вроде Windows/Fonts и ещё лучше квоты, после чего забиваешь место на системном разделе в ноль, нтфс приплыла (да, я знаю, что _сейчас_ нормально реагирует, но из года в год это самая частая причина для утраты данных). Ситуация, благодаря сомнительным апдейтам, не такая уж фантастическая. По поводу "распаковки тысяч мелких файлов" вообще не понятно, к чему упомянуто, я разве где-то говорил что она от этого рассыпется? Доступ к файлам тормозит из-за кучи абстракций и мелкие файлы тормозят особенно ощутимо.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 16:57
	> Хорошо, давай вместо твоего пустословия я приведу самый надёжный способ её уничтожить, > который работал на протяжении многих лет. Включаешь сжатие какого-нибудь бесполезного > каталога вроде Windows/Fonts и ещё лучше квоты, после чего забиваешь место > на системном разделе в ноль, нтфс приплыла (да, я знаю, что > _сейчас_ нормально реагирует, но из года в год это самая частая > причина для утраты данных). Ситуация, благодаря сомнительным апдейтам, не такая уж > фантастическая. По поводу "распаковки тысяч мелких файлов" вообще не понятно, к > чему упомянуто, я разве где-то говорил что она от этого рассыпется? > Доступ к файлам тормозит из-за кучи абстракций и мелкие файлы тормозят > особенно ощутимо. VirtualBox поставить и записать видео - делов на полчаса. Увы, не верю ни слову, пока не увижу видео доказательства. Желательно на свежей версии Win10/11, которые скачиваются за 10 минут с оф сайта: https://www.microsoft.com/software-download/windows10 Test case вымученный до ужаса: сжатие + нулевое свободное место, надо признать. Случается примерно у одного человека из миллиарда. Большинство Linux FS не поддерживают сжатие вообще, в такой ситуации и ваши хвалёные ZFS BTRFS встанут колом поди.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (8), 28-Май-23, 17:22
	Ну нет, тебе надо, ты и экперементируй. Лет 5 назад в очередной раз пофиксили. Ещё с шифрованием можно поиграться. Она выполняет недопустимые фоновые операции над метаданными, для которых ресурсов нет, и от это всё разлетается. Я чёт сомневаюсь, что линуксовые ФС будут иметь такую логику, разносящую суперблок, или выполнять подобные операции. А на виртуалке не обязательно прокатит, в них логика работы с данными всё же отличается от реального железа (хотя именно это -- вполне вероятно). Учитывая, что winsxs в венде всегда разрастался на сотни гигабайт, занимая системный раздел любого объёма, а очередной драйвер звуковой карты после обновления установит десятки гигабайт веб-серверов на все порты и забудет ещё сотню гигабайт временных файлов на системном диске (и это ещё студию и офисы устанавливать не начали), то тут ничего необычного как раз. Система дельта-обновленений венды тоже иногда интересно работает, устанавливая новую ОС вместо кучи старых пакетов.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 17:57
	>[оверквотинг удален] > разносящую суперблок, или выполнять подобные операции. А на виртуалке не обязательно > прокатит, в них логика работы с данными всё же отличается от > реального железа (хотя именно это -- вполне вероятно). > Учитывая, что winsxs в венде всегда разрастался на сотни гигабайт, занимая системный > раздел любого объёма, а очередной драйвер звуковой карты после обновления установит > десятки гигабайт веб-серверов на все порты и забудет ещё сотню гигабайт > временных файлов на системном диске (и это ещё студию и офисы > устанавливать не начали), то тут ничего необычного как раз. Система дельта-обновленений > венды тоже иногда интересно работает, устанавливая новую ОС вместо кучи старых > пакетов. Вы сделали громкое заявление о кривизне NTFS. The burden of proof лежит на Вас, уважаемый. Пожалуйста, не увиливайте. Инструменты у Вас есть. Примерно час на то, чтобы продемонстрировать бесконечный поток пока что голословных обвинений.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 12:44
	> xfs - для десктопа или ноута не лучший выбор. ну почему-же. Если хозяин балуется монтажом видео, например, то наилучший. Да и вообще, почти всегда прекрасный выбор. Другое дело, что в последнее время стала вытесняться btrfs, несмотря на падение производительности -- снэпшоты и лёгкость бэкапа часто перевешивают. > btrfs - претендует на универсальность, но, на практике, проигрывает в производительности xfs, это обратная сторона универсальности. с другой стороны, btrfs-ные снэпшоты, это очень сладко, в случае БД тоже.
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	120. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от ptr (??), 27-Май-23, 13:09
	> Если хозяин балуется монтажом видео В этом случае различия между xfs и ext4 он просто не заметит. > btrfs-ные снэпшоты, это очень сладко, в случае БД тоже Зачем они тому же PostgreSQL, который и так на снапшотах живет? В лом pg_export_snapshot/SET TRANSACTION SNAPSHOT использовать, когда это надо? Это даже не считая того, что снапшот на уровне БД и на уровне ФС - очень разные вещи. В БД, до фиксации транзакции, модифицированные страницы могут быть только в оперативке. А снапшот на уровне файловой системы, если WAL и tablespace на разных дисках, как рекомендуется, - вообще бессмыслен.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 13:19
	>>Если хозяин балуется монтажом видео >В этом случае различия между xfs и ext4 он просто не заметит. проверено -- заметит. особенно, если паралелльно сборки проекта не ждать и плевать в потолок, а заниматься другой полезной деятельностью. > Это даже не считая того, что снапшот на уровне БД и на уровне ФС - очень разные вещи. это всё совершенно очевидно, но иногда нужно быстро получить полную копию базы, которая в дальнейшем будет жить своей жизнью. И btrfs'ные снапшоты тут очень вкусное решение, даже если и на разных дисках (при остановке базы, конечно).
	Ответить | Правка | Наверх | Cообщить модератору

	122. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от ptr (??), 27-Май-23, 13:29
	> при остановке базы, конечно Понял. Мы с разных планет. На моей, остановка БД - чрезвычайное событие, граничащее с катастрофой. А плановые остановки для обновления СУБД планируются исключительно на ночь перед длинными выходными.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 13:33
	> На моей, остановка БД - чрезвычайное событие это тоже понятно. но когда остановка -- снэпшот -- перезапуск посгресса занимает, примерно, 15 сек и юзер даже не отваливается, почему бы нет? конечно, у меня задачи совсем ласковые и игрушечные, на остановку и на 15 минут ругани почти не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от ptr (??), 27-Май-23, 13:49
	А если юзер ждет завершения обучения модели, которое длится уже часов 30? На моей планете, БД без единой активной транзакции - чудо или последствия катастрофы. > 15 сек Cнапшот через pg_export_snapshot делается моментально (<1 mc) на активной СУБД. > юзер даже не отваливается Расскажите подробней, как Вам удается восстанавливать открытые клиентом курсоры при перезапуске СУБД?
	Ответить | Правка | Наверх | Cообщить модератору

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

	137. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 14:44
	> Расскажите подробней, как Вам удается восстанавливать открытые клиентом курсоры при перезапуске СУБД? никак :) и тем не менее, технология имеет право на жизнь в своих граничных условиях.
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	190. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Kuromi (ok), 27-Май-23, 23:04
	Если хозяин балуется монтажем видео ему надо в сторону SSD смотреть, может даже f2fs пощупать...(осторожно правда).
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	206. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 28-Май-23, 06:50
	спасибо, кэп. но вот у мне, например, в голову не придёт покупать ссд большого объёма под эти задачи: монтаж для дома и семьи в жизни не окупится. и кстати, на "моих" ссд -- xfs и btrfs, смысла в камасутре с f2fs как-то не вижу.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Kuromi (ok), 28-Май-23, 17:06
	> спасибо, кэп. > но вот у мне, например, в голову не придёт покупать ссд большого > объёма под эти задачи: монтаж для дома и семьи в жизни > не окупится. > и кстати, на "моих" ссд -- xfs и btrfs, смысла в камасутре > с f2fs как-то не вижу. Ну на самом деле обычно всякие "топовые" NVME с 3-7 гигабайта в секунду записи (и SLC mode на треть накопителя, чтобы из кэша не вылететь) под штуки вроде видеомонтажа и покупают, ибо иначе смысла в таких линейных скоростях просто нет (ну читаете вы гигабайтный файл не треть секунды, а одну седьмую, разница уже незаметна). Так что сам дохтур прописал. Что же до f2fs, то я вот сколько лет пользую (успешно), столько наблюдаю странно предвзятое отношение к ней, одна половина говорит "нестабильно", другая "ненужно". Мол, зачем нам ФС с оптимизацией под Flash\SSD если SSD прекрасно сами выравнивают износ, значит ненужно, хотя оптимизации f2fs никак НЕ УВЕЛИЧИВАЮТ износ, так что неясно почему тогда условная ext4 не "не нужно". При этом багфиксы и новые фичи f2fs прилетают в ядро регулярно, развитие есть(+шифрование +сжатие +атомарные операции, даже объединение нескольких устройств в одну ФС завезли), а производительность - отличная. Но нет, оно "ненужно", зато целых три новые SSD-friendly файловые системы - bcachefs, NOVA и SSDFS, на подходе. Вот они точно будут "нужно", наверное.
	Ответить | Правка | Наверх | Cообщить модератору

	314. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 30-Май-23, 09:05
	У f2fs была проблема с GRUB. Если создать ФС с опцией -O extra_attr, загрузчик не может её читать. То есть надо создавать отдельный раздел под boot. А это может быть не каждому эксперту под силу, что и объясняет недовольство.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Kuromi (ok), 30-Май-23, 15:48
	> У f2fs была проблема с GRUB. Если создать ФС с опцией -O > extra_attr, загрузчик не может её читать. То есть надо создавать отдельный > раздел под boot. А это может быть не каждому эксперту под > силу, что и объясняет недовольство. Есть такая проблема, да.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 27-Май-23, 14:52
	> Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система,  которая просто работает? > Как например NTFS? Ну я пользуюсь, просто работает, брат жив. Но обратите внимание, нюанс: ntfs-3g Если тебе линейный доступ к средних размеров файлам и все больше по чтению - и больше ничего вообще не надо, ни сложных прав доступа, ни EA, ни, Б-же упаси, виндовых штук - просто работает, да. Нормальные еще разработчики писали, а в силу изоляции от стабильного нонсенса - не смогли поломать.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	301. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:46
	> Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо. ... >  которая просто работает? Как например NTFS? Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных. Да так что не монтируется и не чинится chkdisk'ом иной раз. В силу природы ФС это еще и без предупреждений зачастую. Т.е. все выглядело ЗБС - а сегодня оно не маунтится или драйвер в бсод летает. Но если что в линух завезли ядерный полноценный драйвер этсамого, так что кто NTFS хотел может его и юзать. Хоть я и не понимаю прелести в тормозной файлухе из 90х которая требует условный "fsck" и не демонстрирует вообще совсем ничего выдающегося.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	316. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Kuromi (ok), 30-Май-23, 16:42
	>[оверквотинг удален] >>  которая просто работает? Как например NTFS? > Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных. > Да так что не монтируется и не чинится chkdisk'ом иной раз. > В силу природы ФС это еще и без предупреждений зачастую. Т.е. > все выглядело ЗБС - а сегодня оно не маунтится или драйвер > в бсод летает. > Но если что в линух завезли ядерный полноценный драйвер этсамого, так что > кто NTFS хотел может его и юзать. Хоть я и не > понимаю прелести в тормозной файлухе из 90х которая требует условный "fsck" > и не демонстрирует вообще совсем ничего выдающегося. NTFS конечно ФС старая и на сегодняшний день не предлагает ничего такого что не было в других ФС (деревья, экстенты, журнал - все это давно есть), хотя на момент своего создания это был прогресс. Однако тот факт что разрабы BTRFS не осилили сделать нормальный btrfs.fsck не значит что это норма...
	Ответить | Правка | Наверх | Cообщить модератору

	342. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 22:26
	>предлагает ничего такого что не было в других ФС (деревья, экстенты, журнал - все это давно есть) Экстенты ??? Откуда HTFS взяться экстентам,будь они там она не была такой тормозной,но теряла бы файлы гораздо чаще, мда...Она как и фат (почему конвертация возможна) использует кластеры и карту свободного пространства.Кластер это что то типа инода  в юних спецификации.Может не совпадать по размерам с сектором жесткого диска.Есть фича фс -может пространство заполненное нулями упаковывать.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Kuromi (ok), 31-Май-23, 22:41
	>>предлагает ничего такого что не было в других ФС (деревья, экстенты, журнал - все это давно есть) > Экстенты ??? Откуда HTFS взяться экстентам,будь они там она не была такой > тормозной,но теряла бы файлы гораздо чаще, мда...Она как и фат (почему > конвертация возможна) использует кластеры и карту свободного пространства.Кластер это > что то типа инода  в юних спецификации.Может не совпадать по > размерам с сектором жесткого диска.Есть фича фс -может пространство заполненное нулями > упаковывать. Чтож, закапываться в спеки лень, но условная Википедия (да простят меня боги) уверена что экстенты в NTFS есть. С другой стороны та же Википедия не знает что у F2FS есть поддержка нескольких устройств, так что... Кстати конвертация из FAT ни о чем не говорит. EXT3 прекрасно конвертируется в EXT4, вот только старые файлы остаются битмаповыми (не-экстентами) до тех пор пока их не перезапишешь или явно не сделаешь chattr -e файлу.
	Ответить | Правка | Наверх | Cообщить модератору

	347. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 23:21
	В журнале Системный администратор приводилась статья по устройству ntfs, достаточно подробная.Не слова об экстентах.А проблема фрагментации ? При использовании экстентов и карты свободного места -файл писался бы крупным куском.Если только сейчас не добавили в виндовс  10-11.Кстати в русской версии вики тоже не слова об экстентах.На странице http://www.vsokovikov.narod.ru/New_MSDN_API/File_system/ntfs... тоже насчёт экстентов помалкивают,упоминают только что может выделять непрерывную область,но логически все равно это блок кластеров.
	Ответить | Правка | Наверх | Cообщить модератору

	333. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 10:27
	> Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных. > Да так что не монтируется и не чинится chkdisk'ом иной раз. > В силу природы ФС это еще и без предупреждений зачастую. Зато инструментов для вытаскивания данных до хрена и больше,а если еще и образ был MFT так в 80% починишь.С нее реально если сжатие не включено хорошо инфа вытаскиваеться,а бсод это вин проблемы.(Было уже - на 7-10 обнаружена проблема с альтернативными потоками проблема-определенное название файла,бсод,диск поврежден,правда в 90% случаев исправлялась ошибка). В 50% где не работало под виндовс-  монтировалось под дос или linux.А придупреждения есть - но кто будет заглядывать в администрирование,просмотр событий .А в журнале есть частенько сообщения о проблемах с бад блоками,MFC (используеться копия) или бад миссинг с непонятными номерами -источник сообщения драйвер ntfs//
	Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

	326. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (324), 31-Май-23, 01:55
	Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка и папка это одна директория, открывающие случайные данные? Это та фс, где нет нормальных симлинков? Которая поддерживается примерно нигде (несколько кривых версий в винде, несколько кривых версий в линухе)? Эта та самая одна из медлительнейших ФС? Ну если она просто работает, то любая из ФС покажется вам вершиной технологий.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	334. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 31-Май-23, 10:50
	> Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка > и папка это одна директория, открывающие случайные данные? Это та фс, > где нет нормальных симлинков? Которая поддерживается примерно нигде Сейчас с 64 мгб кэша на жестких любая фс при резком выключение может сказать -да ну его на "буй". Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы.И симлинки и хардлинки данная фс поддерживает,софт не поддерживал,вот в этом беда.Даже больше скажу-ее можно было (хр,виста) под виндой монтировать если вы не знали.Да да,монтировать,а не буквой обозначать (кроме диска с). И не особо она медлительная-замечательно тюненгуеться,если стальные яйца можно даже журнал отключить.А с коммерческими драйверами спокойно под линь и 60 мгб выжимали.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 31-Май-23, 16:02
	> Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка > и папка это одна директория, открывающие случайные данные? Вы путаете ФС и ОС. В NTFS это разные директории. В NTFS даже 0 (байт значения 0) может быть в середине имени.
	Ответить | Правка | К родителю #326 | Наверх | Cообщить модератору

147. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
Сообщение от Аноним (147), 27-Май-23, 16:02
Вы новость вообще читали? Chris Caudle 2023-05-19 14:00:28 UTC Updated to kernel 6.3.3 from updates testing repository. Several minutes after logging in again I began to get errors indicating that some files could not be written.  Shutdown with systemctl and while rebooting a filesystem error was detected and the system dropped to single user rescue mode.
Ответить | Правка | Наверх | Cообщить модератору

	186. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (256), 27-Май-23, 21:55
	А вы? Человек загрузился в 6.3.3 и у него все прахом пошло. И дальше у пачки других.
	Ответить | Правка | Наверх | Cообщить модератору

151. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
Сообщение от onanim (?), 27-Май-23, 16:41
о, я смотрю тут специалисты по XFS сидят. подскажите, что вот это за фигня: https://files.catbox.moe/t4qvod.png симптомы: через несколько дней аптайма сервер внезапно зависает и перестаёт отвечать по SSH, скриншот сделал из IPMI. в гугле по "ctx ticket reservation ran out" ноль (zero(null(nil))) результатов. ось CentOS 7, ядро 6.2.8, объём фс 24ТБ, нагрузка на фс минимальная - до 20 мегабит в секунду R+W.
Ответить | Правка | Наверх | Cообщить модератору

	155. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 27-Май-23, 16:49
	а ну и в dmesg никаких ошибок, в SMART у хардов всё шикарно, никаких внезапных отключений питания отродясь не было - сервер подключён к UPS. железо точно рабочее, потому что раньше на этих же хардах была ext4, переформатировал в XFS по рекомендации гугла - для большого количества мелких файлов.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от пох. (?), 27-Май-23, 16:56
	> а ну и в dmesg никаких ошибок а это на экране что по-твоему? В логах - естественно никаких ошибок, ты ж их сложил поди на ту самую fs? И то что у тебя на экране - очевиднейшим образом не проблема железа. Это проблема переполнения каких-то внутренних структур. > переформатировал в XFS по рекомендации гугла хотел порекомендовать у гугла и спрашивать, как теперь это чинить, но вспомнил что ты уже спросил ведь.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (109), 27-Май-23, 17:17
	Ты ведь на самом деле хотел сказать вернуть ext4 и убрать xfs.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 27-Май-23, 18:05
	вот я к этому же решению и склоняюсь. за ~15 лет прыщеводства ни разу не сталкивался с проблемами с ext4, зато с btrfs и теперь xfs поел коричневого добра.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 28-Май-23, 00:03
	> за ~15 лет прыщеводства ни разу не сталкивался с проблемами с ext4 э...ну... короче, у меня для тебя плохие новости - тебе просто везло. (Или может ты просто каждый раз выбирал xfs там где оно могло случиться) Не, такой вот тошнотины чтоб хрясь-пополам с неведомой хренью в логах - да, не было, пока еще - это фирменная фишка именно xfs, как фирменная btrfs превратиться в невосстановимую мешанину вообще без предварительных симптомов. Но silent filesystem corruptions и проблемы восстановления - это норм и для ext4.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 28-Май-23, 06:44
	я бы склонялся к гипотезе, что проблема где-то ближе к железу. Просто на ext* не повезло наткнуться явно, но это не значит, что неприятностей нет, они мог быть до поры просто хорошо прятаться.
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	156. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от пох. (?), 27-Май-23, 16:53
	> объём фс 24ТБ "слабоумие и отвага" или "слабоумие и слабоумие"?
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	165. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 27-Май-23, 18:09
	я понимаю, что у вас в кровавом ынтырпрайзе на хранилища объёмом менее чем 1 петабайт смотрят как на добро, но что нам, бомжарам, делать?
	Ответить | Правка | Наверх | Cообщить модератору

	194. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 28-Май-23, 00:00
	Наоборот, у нас полка не позволяет создать один том больше 18 терабайт. Вообще. Никак. Ну она немного устаревшая, конечно. Но в целом лимит и на сегодняшний день выглядит вполне разумным. Хотя ntfs прекрасно себя чувствует до 64T, и с некоторыми извращениями - до 120. Но - не советую.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (109), 27-Май-23, 17:16
	Проблема не в сервере и не ос, а в том что у тебя поисковый кретинизм, легко ищутся упоминания https://www.spinics.net/lists/linux-xfs/msg58037.html https://lore.kernel.org/all/20211210000956.GO449541@dre.../ Я не вчитывался, но там вроде у народа всё заработало, потом.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	164. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 27-Май-23, 18:07
	> поисковый кретинизм > About 7 results (0.25 seconds) > результаты поиска: исходный код ядра линукс и ссылка выше, которую я уже открывал и решения не увидел
	Ответить | Правка | Наверх | Cообщить модератору

	197. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от пох. (?), 28-Май-23, 00:05
	ипать, иксперт опеннета - нашел таки гуглем - тадам - исходник с этой строчкой. Знаешь, я ее мог бы грепом прямо по локалхосту найти - у меня есть /usr/src/linux Разобраться когда эти грабли могут вылезать и что вообще там такое происходит - это вот несколько сложнее. Мне не хочется.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	160. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 27-Май-23, 17:27
	насколько я понимаю, это переполнение при транзакции и ненормльно. надо бы в техподдержку дистрибутива. центос...
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	199. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от пох. (?), 28-Май-23, 00:07
	"это правда был несчастный случай? - Случай, когда человеку в спину попадает стрела - трудно назвать счастливым." Знаете ли, сэр, крэшащаяся операционная система это само по себе ненормально. Техподдержка дистрибутива это да, довольно смешно.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 28-Май-23, 06:40
	а кто спорит? Конечно, ненормально. Но ниже Вы сами сказали о "большом нечто". Слишком сложно всё это стало, существующие методы отладки и разработки, вероятно, неадекватны таким большим системам с быстропротекающими взаимодействующими процессами: у Майкрософта дела не лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 28-Май-23, 07:05
	и да, про техподдержку не очень смешно: как минимум, они должны убедитьтся, что ядро гнилое и надо рекомендовать заменить (и на что). стендовые возможности у нормальной техподдержки должны быть.
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	250. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Анннннно (?), 28-Май-23, 19:42
	Это ж каким кретином нужно быть, чтобы на CentOS 7 воткнуть неродное для CentOS ядро? Ты либо программист-ядерщик из Оракла, либо васян-локалхостоадмин. Иди лечись.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	283. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от onanim (?), 29-Май-23, 12:49
	> Это ж каким кретином нужно быть, чтобы на CentOS 7 воткнуть неродное > для CentOS ядро? Ты либо программист-ядерщик из Оракла, либо васян-локалхостоадмин. Иди > лечись. а кто тогда ты, если не знаешь про свежие ядра в родных репозиториях ред хата?
	Ответить | Правка | Наверх | Cообщить модератору

	322. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Анннннно (?), 30-Май-23, 22:18
	> а кто тогда ты, если не знаешь про > свежие ядра в родных репозиториях > ред хата? Ссылку на *официальное* ядро 6.2.8 от *RedHat* для *CentOS-7*, или ты п***абол.
	Ответить | Правка | Наверх | Cообщить модератору

167. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
Сообщение от Аноним (167), 27-Май-23, 18:40
Все эти исправления больше похожи на танцы с бубном. Терминам "похоже", "вроде бы", "чуть больше", "менее стабильно" и т.п. - нет места в инженерном деле.
Ответить | Правка | Наверх | Cообщить модератору

	200. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от пох. (?), 28-Май-23, 00:12
	Линукс это давно уже сборник шаманских практик а не инженерия. Никто не знает точно как работает xfs (или любое другое большое нечто в ядре) Собственно - 12309, баг о котором достоверно известно в какой версии его точно нет - так и не выявлен. Тоже похоже, вроде бы, произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда. А то дискредитируют, гады.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от birdie (ok), 28-Май-23, 12:49
	Баг закрыли, потому что туда посыпался спам - я не про комментарии, я про обычный email spam: https://i.ibb.co/3Wx78Wd/spam.webp Баг я отрыть могу, потому что есть права на kernel bugzilla: Konstantin Ryabitsev 2020-03-04 01:33:32 UTC > I'm making this bug private to prevent more spam from being added to it.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 28-Май-23, 17:25
	ну полно сказочки-то рассказывать. Баг не просто закрыли, страницу багзилы сделали недоступной для недопущенных к столику. Есть миллион более простых способов заблокировать спам, но был выбран именно этот - попрятать крошки под ковер. К сожалению есть вебрахив и он всех палит. P.S. админские навыки владельцев кернельной багзилы, конечно тоже на высоте, но что-то никто и не удивлен.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 17:55
	> ну полно сказочки-то рассказывать. Баг не просто закрыли, страницу багзилы сделали недоступной > для недопущенных к столику. Есть миллион более простых способов заблокировать спам, > но был выбран именно этот - попрятать крошки под ковер. > К сожалению есть вебрахив и он всех палит. > P.S. админские навыки владельцев кернельной багзилы, конечно тоже на высоте, но что-то > никто и не удивлен. 1. Bugzilla открыта для new bug reports - you're welcome 2. Reproducible test case - где? Вместо этого "Буду обижаться, ненавидить, говорить, что де "закрыли и спрятали, гады"". Всё, что нужно знать о фанатах Open Source.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от пох. (?), 28-Май-23, 18:22
	> Reproducible test case - где? в момент появления бага их было полно. Не было желания. Не у нас, сам понимаешь - даже я тогда еще все же надеялся что усилия не совсем напрасны. Сейчас, извини, доставать из под шкафа ту самую 2.6.13 где бага нет, собирать обратно ржавый пень3 и предлагать тебе воспроизводимый сценарий просто нет никакого смысла. Код двести раз переписали, проблема никуда не делась, только замылилась потому что современное железо чаще может ее переварить более-менее без последствий. Надо было тогда откатывать новый улучшенный планировщик, раз даже его авторы не могли понять почему он иногда работает неправильно. Число патчей было еще вполне счетным. Но давать заднюю эти ребята были не обучены - ведь на их локалхосте все работало даже лучше чем до того. Учитывая кто и сколько времени потратил в попытках не меняя главного подкостылить и подпереть локальные проявления проблемы - я не очень верю в то, что сейчас еще можно что-то исправить. Для отдельных кейсов - наверное можно (сколько раз проблему объявляли исправленной - теперь желающие могут посмотреть сами). Вылезет у меня еще где-нибудь - принесу показать. Но вряд ли уже - я практически перестал использовать линуксы в повседневной жизни. Какой-то я давно уже антифанат этого фресофтваре.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 19:18
	>[оверквотинг удален] > могли понять почему он иногда работает неправильно. Число патчей было еще > вполне счетным. Но давать заднюю эти ребята были не обучены - > ведь на их локалхосте все работало даже лучше чем до того. > Учитывая кто и сколько времени потратил в попытках не меняя главного подкостылить > и подпереть локальные проявления проблемы - я не очень верю в > то, что сейчас еще можно что-то исправить. > Для отдельных кейсов - наверное можно (сколько раз проблему объявляли исправленной - > теперь желающие могут посмотреть сами). Вылезет у меня еще где-нибудь - > принесу показать. Но вряд ли уже - я практически перестал использовать > линуксы в повседневной жизни. Какой-то я давно уже антифанат этого фресофтваре. Ждём-с.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:52
	> 1. Bugzilla открыта для new bug reports - you're welcome > 2. Reproducible test case - где? > Вместо этого "Буду обижаться, ненавидить, говорить, что де "закрыли и спрятали, гады"". > Всё, что нужно знать о фанатах Open Source. Пох такой себе фанат опенсорса, который назло бабушке уши отмораживает и винду ректамит. Его юниксвэй для него же и не сработал. Настолько что он рекламит винду. Так что учитывать его мнение в контексте опенсорса - лучше просто проигнорить. Хотя иногда, примерно в 5% случаев он дело говорит. Но фильтровать 95% бездарного спама или протухшей информации 10+ лет свежести утомительно и если вы не знаете его причуды - лучше совсем игнорьте. Потому что ткнув в профайл можно заметить что это эксперт по прострелу пяток под линухом. Хотите так же? Нет? Вот и не делайте как он! Это же элементарно, Ватсон :)
	Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

	231. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 28-Май-23, 16:50
	> Линукс это давно уже сборник шаманских практик а не инженерия. > Никто не знает точно как работает xfs (или любое другое большое нечто > в ядре) > Собственно - 12309, баг о котором достоверно известно в какой версии его > точно нет - так и не выявлен. Тоже похоже, вроде бы, > произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда. > А то дискредитируют, гады. 12309 у меня до сих пор бывает при копировании крупных файлов, на NVMe диске, хотя раньше "решением" было "купите NVMe SSD вместо SATA SSD", а ещё раньше "решением" было "купите SSD вместо HDD"
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	233. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от birdie (ok), 28-Май-23, 17:01
	>> Линукс это давно уже сборник шаманских практик а не инженерия. >> Никто не знает точно как работает xfs (или любое другое большое нечто >> в ядре) >> Собственно - 12309, баг о котором достоверно известно в какой версии его >> точно нет - так и не выявлен. Тоже похоже, вроде бы, >> произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда. >> А то дискредитируют, гады. > 12309 у меня до сих пор бывает при копировании крупных файлов, на > NVMe диске, хотя раньше "решением" было "купите NVMe SSD вместо SATA > SSD", а ещё раньше "решением" было "купите SSD вместо HDD" Версия ядра? Вывод `free`? Вывод `vmstat 1 5`?
	Ответить | Правка | Наверх | Cообщить модератору

	284. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от onanim (?), 29-Май-23, 12:51
	>[оверквотинг удален] >>> Никто не знает точно как работает xfs (или любое другое большое нечто >>> в ядре) >>> Собственно - 12309, баг о котором достоверно известно в какой версии его >>> точно нет - так и не выявлен. Тоже похоже, вроде бы, >>> произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда. >>> А то дискредитируют, гады. >> 12309 у меня до сих пор бывает при копировании крупных файлов, на >> NVMe диске, хотя раньше "решением" было "купите NVMe SSD вместо SATA >> SSD", а ещё раньше "решением" было "купите SSD вместо HDD" > Версия ядра? Вывод `free`? Вывод `vmstat 1 5`? разные дистрибутивы, разные относительно свежие LTS ядра, разные диски (SATA SSD и NVMe), оперативы от 16 до 64 гб, и везде копируешь тяжёлый файл - получаешь тормоза в гуе.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 02:56
	А ядра то надеюсь десктопные, low latency? :) Т.е. как минимум preempt_dynamic/preempt_rt. Не, это надо не только тем кто с звуком работает. Но и всем кто предпочитает отзывчивый десктоп а хотя-бы и ценой потери пары пунктов в бенчмарках. Видите ли обычные ядра - для серверов и они bulk performance ценят выше чем латенси. А вот юзер ожидающий переключения задачи или что там еще может быть сильно иного мнения на этот счет.
	Ответить | Правка | Наверх | Cообщить модератору

273. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
Сообщение от Kirikekeks (ok), 29-Май-23, 08:01
Я в домашней лабе Центоси уже обновился, так что отчаиваться поздно. Все бэкапные диски на ext4. Словил последствия своей ошибки - переделал lvs-lxc ВМ с xfs на ext4, но fstab не поправил. После обновления ядра стал убегать из системы диск с этой ВМ целиком /dev/sda (а там таких тестовых ВМок 6шт). Исправил fstab и потерял данные дней за 20 безвозвратно, на этой ВМке, остальные 5 норм, восстановился из бэкапа. Сам виноват. Но на всякий случай сообщаю. Ошибка воспроизведётся, если кому интересно, вдруг в природе еще есть такой забывчивый.
Ответить | Правка | Наверх | Cообщить модератору

287. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
Сообщение от Анонус (?), 29-Май-23, 16:05
Предложен патч, исправляющий проблему -    args->fsbno = ap->blkno; +     args->alignment = 1; Заметили, да? > fsbno Опять эти русские хакеры!
Ответить | Правка | Наверх | Cообщить модератору

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

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