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

"В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS"	+/–
Сообщение от opennews (??), 26-Май-23, 23:36
В опубликованном в конце апреля выпуске ядра Linux 6.3 выявлена ошибка, приводящая к повреждению метаданных файловой системы XFS.... Подробнее: https://www.opennet.me/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 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (-), 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 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (-), 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 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

	362. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 01-Июн-23, 09:09
	>Единственное известное исключение это рейзер где убиение тома fsck - "known issue" :) Эх,байки времен V3.5 .В 3.6 это починили -единственное исключение chroot для виртуальных томов (виртуальные машины) ,там да,обнаружив по сигнатурам знакомые файлы fsck сносило голову. Мелкие ошибки fsck нормально ремонтировало,сколько reset я пережил не счесть.Но забросили эту фс :-( ,т.к ext4 более предсказуема вела,а вариант с очень мелкими файлами в гиганских кол-вах редко распрастранен.
	Ответить | Правка | Наверх | Cообщить модератору

	373. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (373), 01-Июн-23, 19:22
	> Эх,байки времен V3.5 .В 3.6 это починили -единственное исключение chroot для виртуальных > томов (виртуальные машины) Нормальное исключение, в переводе с кодерского на человеческий "мы не паримся валидацией найденого и втрамбовываем первое похожее на фс в вашу файлуху, так кодить проще!". Проверить что-то типа UUID - не судьба? В современном мире это опасный факап. У лично меня образов других систем с тем же типом рутфс у есть. И если дев говорит что мой кейс ведет к разлету, чинить не бум, known issue, оок! Зачем мне такие технологии? К тому же ядерные апи не мировая константа. С тех пор появились io_uring, folios (группы страниц, чтобы не колупать по 1 странице) и все такое. По причине появления сверхскоростного IO (что сеть, что сторажи) и нужды урезать оверхед по линии ядра соответственно. Более менее живые на это дело отрефакторились. Полутрупики на то и полутрупики и вечно держать для них легаси апи никто не будет. Выкинут вместе с дохляком. > там да,обнаружив по сигнатурам знакомые файлы fsck сносило > голову. Мелкие ошибки fsck нормально ремонтировало,сколько reset я пережил не счесть. А у меня оно с высокой вероятностью вынесло бы ФС, по причине наличия файлов с rootfs, я системные образа собираю и виртуалки использую. И это как бы проблема класса showstopper. > Но забросили эту фс :-( ,т.к ext4 более предсказуема вела, Скорее, потому что технологически оно уже ничем таким не передовое, имеет ряд трудноустранимых проблем (да, в EXT4 fsck не склонен чужие файлухи вкатывать в починяемую), а разработчики самоустранились и пошли атаковать какие-то ветряные мельницы. С Reiser4/5. Не, сама идея редизайна ок, но если девы потом на майнтенанс положат не доведя до ума и не фикся баги, то такие файлухи мало кому надо, независимо от супер-технологий, извините. Роялит сочетание в целом и как оно с реальным миром и его задачами стыкуются, а не супертехнологии в 1 конкретном закутке. > а вариант с очень мелкими файлами в гиганских кол-вах редко распрастранен. Собсстно рейзер3 шустро работает с кучей мелочи вроде. Но по другим эксплуатационным параметрам не ахти. В частности 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 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Виталий (??), 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 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от Аноним (8), 27-Май-23, 14:08
	Всех сливают? Ну да. На самом деле, по производительности и фичам ext4 уступает только ntfs, но ты и так прекрасно это знаешь. Зато вот по надёжности и фрагментируемости она куда лучше.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

	376. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 20:08
	> Порадуете ссылочкой на багзиллу? Если захотите сослаться на боязнь деанона, Титул даденый мне вами тому не способствует. > расскажите, куда заливали образ в пол гигабайта с битой файловой системой, В моих случаях не требовалось: я как правило сам могу локализовать проблему на моей стороне, в том числе и сделав бисект, с точностью до комита. Кажется это способствует шустрому фиксу проблемы и приятным взаимодействиям. Это опенсорс как он задуман изначально. Я слал немелкие образа, правда не девам а знакомым которым датарекавери делал, просто торентом Потому что поблочная верификация и докачка/перекачка битого для 500 гигз - аргумент. DHT-only, без трекеров и акаунтов. А чтоб левые это не скачали, сжал 7z с нормальным паролем, еще и образ раза в 2-3 сжимается заодно. А полгига (вы же только метаданные сняли, если это не опечатка?) можно и просто на любой свой сервак залить. > что бы его круто посмотрели спецы. Для себя я считаю что это МОЯ проблема как мне обеспечить вон то. Это же мне надо а не спецам. Если у вас иначе - ну, удачи. Ну и спецы не глупые и после недолгих переговоров с ними в чатике или почте можно устроить кастомные договоренности как и чего. Разумеется трансфер штук на сотни гиг и терабайты оговаривается "штучно" исходя из технологически возможностей сторон. > И каким образом заливали. Так у btrfs в send есть режим send где он только метаданные снимает, спецом для дебага. Это еще и приваси сохраняет малость, содержимого файлов там нет. > По умолчанию у среднестатистического пользователя нет запасного > накопителя - он просто удаляет систему и ставит родную Бесяточку. Ну он и идет в вон ту датарекавери лабу и платит, если данные надо. А если умничать попытался и таки не смог - получает кратное умножение ценика. За усложнение работ. Действия без понимания что и зачем имеют свойство делать хуже чем было. Лично я и не собираюсь таких тянуть в линух. Если им десяточка лучше, пусть пользуются, для меня это ничего не меняет. Я btrfs советую только продвинутым личностям которые могут врубиться в азы путешествий во времени и мультивселенных. А лучше и в азы устройства этой фс. Так будет просто, логично, понятно, удобно. Без этого всего - это как дикарю дать звездолет, при том что он уверен что планета плоская. Куда он такой полетит? > Априори программа на императивном языке содержит ошибки, её корректность > требует доказательств. Я бы сказал что штуки такой сложностью гарантировано содержат ошибки. Вопрос в их вредности и масштабе. > Частные случаи вроде Вашего для обобщения требуют доказательств по индукции. Всему > этому учат в школе. У меня были более мощные учителя по части процессов вот именно разработки софта. Объяснившие некоторые эмпирические, но зато работающие в реальном мире соотношения. И это ИМХО работает лучше теоретических рассуждений. Со школьными знаниями вы никогда не разработаете мало мальски крупный и успешный софтварный проект. Да и с институтскими тоже. Потому что не рассказывают там вон то. Это можно только в большой корпе самому увидеть.
	Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

	387. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 02-Июн-23, 08:59
	Так мне и не надо, поскольку мне не нужна BtrFS как таковая (скрипт Шишкина до сих пор её забивает до отказа пустым пространством? вот то-то же). Мне надо было пощупать разные ФС и выбрать что-то. Бисект тем более пустая трата времени, когда данные уже убиты. Он мог бы помочь, если ситуация воспроизводится.
	Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

	392. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 09:18
	> Так мне и не надо, поскольку мне не нужна BtrFS как таковая Тут как бы дело хозяйское, но когда из вас не удается выжать даже точное сообщение об ошибке и детали, ценность такого знания, как бы это сказать... я за объективную и актуальную оценку технологий и борьбу с багами. Но по таким данным невозможно сделать никаких выводов. Даже версии кернелов не указаны, блин. Если 2.6.32 - "кто б сомневался?!". Если 6.3 как в сабже - "ORLY?!" > (скрипт Шишкина до сих пор её забивает до отказа пустым пространством? ХЗ. Меня интересуют реалистичные юзкейсы, похожие на мои прежде всего. И поведение фс там. Я их и тестирую. "А если рельсу?" (мужики vs лесопилка из анека) - я не против экспериментов edge case, но их ценность для меня небольшая, потому что я в них никогда не упираюсь. Более прагматичные вещи типа окончания места, даже при каком-нибудь каче торентов проблем сейчас не вызывают. Можно стереть файло и дело с концом. С каких-т о > вот то-то же). Если для вас файловые системы Шишкина работают лучше, пользуйтесь ими :). А ZFS мне на уровне дизайна не нравится. Не с чего этому дизайну быть быстрым. Даже не экстентный толком, архаика. А с ломовым подпором RAM что угодно быстрое, но это не заслуга файлухи и ее структур. Ну и что-то мне подсказывает что с свежими кернелами ZFSникам будет довольно душновато. На выбор или ждать портов черти сколько или будет очень опасное глюкало. Там сейчас апи рефакторят, в том числе vfs и mm и это напрямую затрагивает файлухи. Это очень деликатная совместная игра. И когда игрок не на поле, а где-то там, он ситуацию не видит, и сможет при случае покушать гуана лаптем, имхо. И кстати если уж мы о птичках, а в этом вашем ZFS дефрагер хотя-бы сделали? А то если CoW на механике забить - сами понимаете, "не очень". Оно и с обычными то "не очень" из-за душняка аллокатору. А многодисковый пул разбирать - тоже "не очень". > Мне надо было пощупать разные ФС и выбрать что-то. Ну как бы подход то сам по себе верный. Просто не понимаю откуда взялся вон тот результат, особенно без деталей. > Бисект тем более пустая трата времени, когда данные уже убиты. С точки зрения вот именно убиения данных - там офлайн читалка без монтирования в "btrfs" встроена, с возможностью попробовать разные точки входа (CoW же не сносит старые состояния так сразу, есть >1 варианта как его пытаться распарсить). Так что если вот именно данные, именно нужны, и их вот именно вынуть надо, btrfs ИМХО не хучший в этом аспекте. Для нтфс и фат есть офлайн читалки такого типа - как коммерческие виндовые утили, конечно. Иногда очень помогают, "альтернативный парсинг" без монтирования - с недеструктивным вытаскиванием на ДРУГОЙ стораж штука очень полезная, для вот именно вытаскивания, именно максимума данных. А тут такое прям в родном тулките фс. Вот все бы так. > Он мог бы помочь, если ситуация воспроизводится. Это да. У меня на самом деле "интуиция" прокачана. Нечто типа чувства мащины. Я могу просто угадать что надо сделать, если видел ситуацию лично. Но без данных и ремотно это не работает. Пространство поиска слишком большое. А очевидные факапы уже давно выбиты xfs :)) test suite :) и миллиардом юзеров фэйсбука. Так что нарываться на подобный сценарий можно весьма долго и безуспешно, даже с явным желанием его сообразить.
	Ответить | Правка | К родителю #387 | Наверх | Cообщить модератору

	396. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 03-Июн-23, 17:15
	Похоже, тут один фанат автономной ОС устроил дудос жалобами, и бот всё подряд чистит. Как я понимаю, он же и экзитноды Тора своим поведением блэклистит.
	Ответить | Правка | К родителю #392 | Наверх | Cообщить модератору

	412. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 04-Июн-23, 01:30
	> Похоже, тут один фанат автономной ОС устроил дудос жалобами, Да, бот тут иногда жесткарит, меня правда обычно не полностью выпиливает а скорее скрывает. Я это лечу "сообщить модератору -> распрячьте". Но вообще бот перегибает. Кажется, кроме жалобщика есть и вполне себе абузивные спамеры, судя по логу модерации по некоторым спамерам ну реально рожа кирпича просит. Если мы про фс хотим потрындеть, провоцировать совсем левак наверное не есть айс с их стороны. > и бот всё подряд чистит. Как я понимаю, он же и экзитноды Тора своим > поведением блэклистит. Я пока лишь на ~70% процентов декодировал его эвристику. В остальных 30% подбешивает внезапными сносами или скрытиями сообщений. И мне кажется что спамеров возможно более 1. Хоть я и не анализировал их в деталях, так, лог модерирования посмотрел (ссылка внизу). Если обратить внимание - в логе есть и совершенно отшибленые на голову персонажи.
	Ответить | Правка | К родителю #396 | Наверх | Cообщить модератору

	415. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 04-Июн-23, 08:04
	Тот персонаж, который заявлял про открутку электросчётчика (цена вопроса за одного человека наверное рублей 500, или 6 долларов; а если ему это существенно, значит за него 50% платит бюджет) накрутил мне тогда 20 минусов. При этом он 20 раз зашёл через Тор и написал сообщения, однозначно попадающие под удаления. Бот эти айпишники занёс в серый список, если кто-то через те же ноды что-то написал, сразу попадает под подозрение. При этом активист в десяти других темах делает тоже самое, плюс наверняка во всё подряд помимо минусов хаотично тыкает. А система защиты сайта писалась в расчёте, что атаковать будет кто-то вменяемый, вот и сбоит.
	Ответить | Правка | К родителю #412 | Наверх | Cообщить модератору

	418. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (418), 05-Июн-23, 02:43
	> Тот персонаж, который заявлял про открутку электросчётчика ...меня репортнул модерам/ботам наверное раз 5-10 и это даже потерли. Я прикинул что раз так, в эту игру могут играть и двое. В ответ я репортнул оригинальное сообщение вызвавшее флейм. Вроде прокатило и его вынесли? Я не фанат игры в 1 ворота :P. > (цена вопроса за одного человека наверное рублей 500, или 6 долларов; > а если ему это существенно, значит за него 50% платит бюджет) Да вообще лол. И к тому же - кому как а мне например летом в помещении без кондея не комфортно рядом с пень4 находиться, его выхлоп тепла ощущается прямо рожей при входе в комнату. Даже в холостом режиме. У пней4 с управлением питанием просто никаковски и с их TDP это как бы некий трабл. С стоковым кулером они еще и воют совершенно отвратительно. А кулер на такой TDP который не воет будет стоить побольше чем те мамка+проц, пожалуй. > накрутил мне тогда 20 минусов. При этом он 20 раз зашёл через Тор и написал > сообщения, однозначно попадающие под удаления. Бот эти айпишники занёс в серый список, Ну да. Я заметил что типаж гадит и в долгу не остался репортнув его оригинальный наброс. > если кто-то через те же ноды что-то написал, сразу попадает под подозрение. > При этом активист в десяти других темах делает тоже самое, > плюс наверняка во всё подряд помимо минусов хаотично тыкает. А система > защиты сайта писалась в расчёте, что атаковать будет кто-то вменяемый, вот и сбоит. Я так понмиаю что защита в основном от спамботов, а тут "бот" условный, забагованый. Интеллекта не сильно больше - но более рандомный и хаотичный, антиспам боты и тригерятся.
	Ответить | Правка | К родителю #415 | Наверх | Cообщить модератору

	420. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 05-Июн-23, 09:07
	>> Тот персонаж, который заявлял про открутку электросчётчика > ...меня репортнул модерам/ботам наверное раз 5-10 и это даже потерли. > Я прикинул что раз так, в эту игру могут играть и двое. > В ответ я репортнул оригинальное сообщение вызвавшее флейм. Вроде прокатило и > его вынесли? Я не фанат игры в 1 ворота :P. Гипотетически здесь три модератора, а практически у Максима нет времени во всем разбираться. Жалобы  от Анонима на другого Анонима лишь увеличивают энтропию. Если тот персонаж такой активист, ну пусть своё время и тратит активнее, тем более что сносится автоматически. >> (цена вопроса за одного человека наверное рублей 500, или 6 долларов; >> а если ему это существенно, значит за него 50% платит бюджет) > Да вообще лол. И к тому же - кому как а мне > например летом в помещении без кондея не комфортно рядом с пень4 > находиться, его выхлоп тепла ощущается прямо рожей при входе в комнату. > Даже в холостом режиме. У пней4 с управлением питанием просто никаковски > и с их TDP это как бы некий трабл. С стоковым > кулером они еще и воют совершенно отвратительно. А кулер на такой > TDP который не воет будет стоить побольше чем те мамка+проц, пожалуй. Я застал время 4-х пней в торговле и знаю, что обычно покупали больше Селероны или АМД, а разницу вкладывали в память-видеокарту, получая в сумме железо мощнее. Тот процессор называли кукурузным и покупался в основном ради понтов. Потому полагал, что он какой-то тролль. Был бы он специалист, даже в трудном положении, ему бы кто-то подарил старое железо получше - торговцам Б/У его подчас складировать некуда. Теперь подозреваю, что он уже всех в своём городе обошёл и обматерил за предложения обновить его любимый процессор задаром.
	Ответить | Правка | К родителю #418 | Наверх | Cообщить модератору

	425. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (425), 06-Июн-23, 00:18
	> Гипотетически здесь три модератора, а практически у Максима нет времени во всем > разбираться. Мир не идеальный. Я под его неидеальности стараюсь адаптироваться. Если какое-то сообщение кажется ценным или принципиальным, я могу бэкапнуть и при случае вывесить вновь. Порой отредактировав в менее едкое, чтобы осталась техническая компонента мысли а не обсуждения персоналий людей. Это фича, памятуя что "...остальные обсуждают людей". > Жалобы от Анонима на другого Анонима лишь увеличивают энтропию. Если какой-то анон назойлив - я начинаю действовать наименее удобным ему способом. Например вынос исходного сообщения - обламывает кайф мелкому жулику на фундаментальном уровне, а заодно рубит предмет флейма. Если кто пытается залочиться на именно меня и выносить именно мои сообщения, я могу выбирать наименее удобные им тайминги или даже менять немного технологии и стиль. Скажем некоторые аноны с номером бывают и мной. Не все, разумеется. Равно как не все Аноним (-) это я. Если кто хочет попытаться трекать всех анонимусов опеннета - окей, круто, это как раз его заякорит и порвет их маленький мозг на тысячи клочков. Может я именно это и хотел? А что, нехай клацают минусы не только нубу но и легиону анонов, нормальный якорь :) > Если тот персонаж такой активист, ну пусть своё время и тратит > активнее, тем более что сносится автоматически. Я ему немного в этом помогаю. С минимальными затратами моего собственного времени. Люблю асимметричные варианты :) > Я застал время 4-х пней в торговле и знаю, что обычно покупали > больше Селероны или АМД, а разницу вкладывали в память-видеокарту, Их больше в офисы ставили. Может, кто ухватил ЭТО нашару когда те их на утилизацию стали сдавать, мало ли. У всяких корп админов иногда можно совершенно даром хардвар получить, порой он даже вполне живой, просто древний. Им иначе еще и утилизацию оплачивать придется и они даже рады если кто утащит. > получая в сумме железо мощнее. Тот процессор называли кукурузным и покупался в основном > ради понтов. Я их видел в офисах скорее - и из за тех свойств их считали куском проблемы, а шиком считалось 64-битная амдшка, все кого я знаю бурно радовались перейда на 64-бит атлоны, оно и воздух грело сильно меньше, и 64 бита это 64 бита, как ни крути :). Это и мультимедии всякой с кодеками, компрессорами и крипто хорошо, и для "продвинутостей" есть где позажигать. Скажем SWAR на 64-бит регистре интереснее чем 32-бит, хоть там как, а в 2 раза больше lanes это в 2 раза больше lanes и фиг оспоришь. > получше - торговцам Б/У его подчас складировать некуда. Теперь подозреваю, что > он уже всех в своём городе обошёл и обматерил за предложения > обновить его любимый процессор задаром. Мне вообще в свое время эн (полу)дохлых мамок всучили чуть не насильно, с аргументом что я электроникой и компами интересуюсь. Я сперва думал что нафиг они мне. Потом купил паялку - получил полкило зачетных силовых FET нашару, продвинутые конденсаторы и заодно тренировочные кошки для отпайки BGA. А потом я обнаглел и сделал реинжиниринг некоторых преобразователей питания под свои нужды. А чо, многофазные синхронные понижайки это круто и продвинуто, тем более что даташиты есть. И изначально на десятки ампер. И совсем не обязательно именно 1 с чем-то вольта Vcore делать. Можно в принципе "что угодно ниже 12V" если немного подумать (повышать тоже можно, но сложнее и реже надо). Появился выводок для питания всякого разного от 12V ("свинцовые акумы") на продвинутых чипах, халявно. Такие чипы даже на дижикее каком заманаешься покупать, это в основном вагонами производителям мамок уходит а для DIY и мелочи слишком сложно, не особо возят.
	Ответить | Правка | К родителю #420 | Наверх | Cообщить модератору

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

	307. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от 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 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от 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ообщить модератору

	361. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от n00by (ok), 01-Июн-23, 08:41
	>> Я поступил ровно так же, как в случае с ZFS. Набрал в >> поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить. > Я бы не назвал идею что-то делать с фс по советам из > интернета от хз кого удачной идеей. Это как раз один из критериев, почему BtrFS непригодна для дома. По ZFS имеется документация от Оркала. > Разработчики, или хоть топичные форумы, > чаты и рассылки сильно лучше. Это не годится. В торговле такой финт называется навязанная услуга. >> Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа >> не дождался - как всегда внезапно понадобился. > А это был что? HDD? SSD? Ну и там достаточно было снять > метаданные без данных с него, у btrfs есть такой вариант, спецом > для багрепортов и воспроизведения багов. Только метаданные - сильно легче и > их хранить не особо напряжно. Но да, это слегка продвинутости, для > тех кто настроен с вылезшей проблемой зарубиться. Т.е. нормальных опенсорсников. Это SSD с ионисторами, где производитель обещает завершение операций записи при отказе питания. Слишком много действий для восстановления данных - не годится для дома. Проще взять из резервной копии и ФС снести к чертям.
	Ответить | Правка | Наверх | Cообщить модератору

	382. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 02-Июн-23, 03:24
	> Это как раз один из критериев, почему BtrFS непригодна для дома. На мой вкус так я и еще эн продвинутых юзерей пользуемся этим всем - в том числе и дома, на десктопах, лаптопах, одноплатниках и роутерах (скачка файлов в фоне или торенты) всяких, и каких-то траблов с этого всего нету. А у меня с энных пор образа для одноплатников на достаточно больших выводках (сотни) на btrfs перешли. А перешли после того как разок пришлось чинить в темпе вальса одноплатник который ВНЕЗАПНО умер. По обидной причине. Там был простой EXT4. И при загрузке - вот 1 бэд случился. Зато - под libc6! Этого хватило чтобы я поимел ВНЕЗАПНОГО гимора. Я обиделся на столь дурной теорвер и стал под образа btrfs с DUP юзать, теперь 1 рандомный бэд не проблема, только в лог матюки и я знаю что да, вон там карточку неплохо б заменить, если повторяется часто, но это именно раннее предупреждение. Играть в это казино можно долго, я отловленые текучки и сыпучки под тестовые сетапы поюазл и пока даже совсем поганые в такое казино вот не проиграли чтоб 2 копии побились в 1 логическом смещении. Так теорвер ощущается намного приятнее. Моя идея в том что с законами природы глупо спорить, ими надо пользоваться на свое благо. Ну вот теорвер в свою сторону крутануть... > По ZFS имеется документация от Оркала. При том эта документация - на версию которая у вас дома очень врядли появится. Откуда бы у вас дома вот оно? Это ж только для соляры. А для линуха это ZoL - сторонние перцы, с отдельным форком этсамого. Развивавшийся независимо. Конечно можно о дельте между форками узнать и вот таким странным способом, но... И чисто практически мне док с вики/readthedocs/мана вроде хватило для понимания что и куда. А со временем я из интереса немного въехал в оющую структуру этой штуки и могу достаточно осмысленно применять фичи на свое благо с минимумом проблем. А вот что с ним надо сделать чтобы он совсем умер - я не знаю. Если б знал относительно честные методы - давно б зарепортил. Пока я видел только юзерей с протертыми SSD-кешами где накопители труху файлухе отдавали, без избыточности, но с такой конфигой - это сами юзеры виноваты что сделали стремный конфиг и не чекали ресурс SSD'шника до момента пока он не протерся в хламину и не начал выгружать труху просто мегабайтами, без копий этого, а на такое в общем никто их ФС не расчитан. >> Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше. > Это не годится. В торговле такой финт называется навязанная услуга. Лол. Если за это деньги брать как рейзер, я еще пойму претензии. Но денег платить не предлагалось. Я лишь сообщил какой вариант для меня самого работал лучше всего. ИМХО отличный вариант для разумных существ имхо. А в опенсорсе еще и культура самообслживания приветствуется, если кто не в курсе. Ну а лучшее что случается это если я смог вычислить мощный баг при помощи вон того зала. А какие-то додики в интернете - они кто и почему я вообще должен на их "клевые" советы время тратить? И главное вас не смущает что сейчас полно блогеров пишут красивые слова чисто для повышения популярности бложика или потрындеть? Достоверность и актуальность этой инфы - полная лотерея. От джекпота до эпикфейла. Чтобы понять что вам подсунули надо как минимум разбираться в этом дизайне ФС и быть в теме на уровне выше среднего, а этого как раз и нету. Я и предложил прийти в места где информированность по топику заведомо выше среднего. > Это SSD с ионисторами, где производитель обещает завершение операций записи > при отказе питания. Обещают все эти господа много где и чего, а что, где и как реально происходит по факту, в реальных условиях - сильно отдельный вопрос, требующий изучения. Ну вон у самсуней EVO некоторые версии фирмварей могут харакири себе вообще сделать если еще удумать обещаной поддержкой TRIM воспользоваться. При том не сразу, а изредка, в определенных ситуациях. Харакири, кстати, в характеристиках не обещают, но я видел достаточно юзеров с ЭТИМ, и их было столько что в майнлайне задолбались и внесли определенные модели и версии фирмварей в блеклист - для них DISCARD форсировано отключен, даже если накопитель и думает что умеет его. Ну вот такой вот оверайд с затыканием чужого фирмварного глюка на уровне кернела. Хотя нормальный фикс это фирмвару глюкастику обновить, конечно. У интелей недавно тоже какие-то обсираки были с некоторыми топовыми SSD, деталей не помню уже. > Слишком много действий для восстановления данных - не годится для > дома. Проще взять из резервной копии и ФС снести к чертям. Я как бы согласен что так быть не должно. И если б мне была известна ситуация когда вот это воспроизводится, я бы ее аннулировал, собрав максимум деталей и пинганув девов. Но у меня на данный момент все работает, потому что все что я знал я и репортнул и плотно впрягся в процесс фикса, и это возымело предсказуемый результат - баги были починены, у меня все просто работает. Да и баги были словлены "правильно", -RC ядрами, так что до реальных продакшнов и не долетели как раз. Да, прогон и валидация -RC требует некоторых затрат времени, но если я уж плотно подсел на линух в моих проектах, я знал на что шел и это... ну... такой вот левелап в линуксе и его скиллах. Когда можно стать сам себе систембилдером, сапортом и в общем-то чем-то типа OEM :). Как по мне это было лучшее что линух мог мне предложить. Хороший апгрейд из консумеров и пользователей в часть процесса :)
	Ответить | Правка | Наверх | Cообщить модератору

	388. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 02-Июн-23, 09:04
	>>> Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше. >> Это не годится. В торговле такой финт называется навязанная услуга. > Лол. Если за это деньги брать как рейзер, я еще пойму претензии. Вместо денег в ходу монета с чеканкой "сделай бисект".
	Ответить | Правка | К родителю #382 | Наверх | Cообщить модератору

	393. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 09:33
	> Вместо денег в ходу монета с чеканкой "сделай бисект". Вообще - вы в чем-то правы. Паразитизм и потребццтво в более-менее живом и успешном опенсорсе не очень приветствуется. Потому что ведет к загниванию проекта и нездоровому климату в экосистеме. И да, это такая себе оплата без оплаты, но мне почему-то кажется что вооон те господа для меня повкалывали сильно больше чем я - для них, поэтому мне грешно жаловаться. А кто хотел, вот натурально, чистым потребителем быть, для него винда есть. За денежку, конечно. Потребители не имеют какого-то внятного смысла в опенсорсе, это ж почти имплементация коммунизма. И да, так то на подумать почему СССР развалился. Ну вот у вас там не удалось воспитание человека разумного. А опенсорсники более менее могут вот. Чисто технически: потребители в конечном итоге обычно встревают в технические проблемы уникальные для себя, никто с оными бороться не хочет или не может - и бай бай, проваливайте на свою дрисняточку или что там у вас, никто не будет скучать об балласте, который получив сотни халявы совсем уж не контрибутит в ответ. Это примерно как торент, можете и не аплоадить, просто будете в самом хвосте списка, получая остатки бандвиза если они есть. А если нет - их получат более полезные клиенты. И хрен такую логику обойдешь, это самозащита сообщества от разрушения.
	Ответить | Правка | К родителю #388 | Наверх | 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ообщить модератору

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

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

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

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

	430. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 20-Июн-23, 06:26
	>> Вы так полагаете, поскольку не изучали ТОЭ, ФОЭТ и прочие удивительные аббревиатуры? Не шили ППЗУ с УФ стиранием? Вот там после нескольких циклов записи-стирания приходилось увеличивать ток в надежде, что получится залить очередную прошивку. Вот это можно зазвать усилением записи. И совершенно внезапно SSD собраны на основе ППЗУ (ЭСППЗУ). > Опять же, все эти замечательные аббревиатеры имеют отношение к сабжу не больше, > чем упомянутые Ньютоны и Амперы. Т.е. никакого. Возьмите за привычку добавлять "по моему мнению", а лучше сразу формулируйте "я не знаю, какое они имеют отношение", пока не узнаете предмет, а не аббревиатуры.
	Ответить | Правка | К родителю #429 | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от Аноним (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. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 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ообщить модератору

	350. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 02:50
	> Потому что он где-то что-то прочёл и эту инфу разносит. Мне почему-то кажется что он для себя этим пользуется, иначе врядли бы знал некоторые вещи. > Инфа необязательно неверна, но это банальная вера, а не знания, полученные > в результате опыта. Опыт тоже штука специфичная. Если вы конечно широко внедрили и попрыгали по граблям от души - там можно делать какие-то выводы. Если были шансы статистику набрать и вообще сунуться немного в тему. А если по паре кейсов делать выводы, можно довольно далеко зайти - а потом окажется что рандом прикололся или что там еще. Это же касается и быстрых выводов без детальных исследований что реально имело место быть. Откуда и пожелание деталей на развал btrfs, например. Для понимания "confidence" данных. Если вы когда-нибудь ставили эксперименты то знаете что иногда можно откушать откровенно бредовых данных, достаточно далеких от истинного состояния дел. В этом случае придется изучить ситуацию лучше и понять что реально не так. Иначе грош таким данным цена в базарный день, имхо. > "Ровно 1000 циклов". А не "более 1000 раз". Ну то есть, откуда > он знает, что более 1000? Считал? И как он столько насчитал?) > Когда погрешность всегда плюс-минус. Я тоже total count не знаю, даже если я в каком-то кейсе прогнал ровно эн, я не трекаю абсолютную сумму. Зато вот например наобум взятый SSD - злопамятный, цуко, и кажет unsafe shutdown count 107. На нем была btrfs с самого начала, сколько-то там лет. И ничего, живой. Unsafe shutdown count это так то - "слет питания без подачи команды на standby режим". И между нами, само это по себе может привести к серьезному факапу, когда фоновая активность фимрвари девайса типа GC и т.п. столкнется с слетом питания - и в хучшем случае - улетом чего-то размером с erase group (десятки мегов) вникуда, и если это случится (имеет полное право согласно спекам стандартов), это в принципе запроектная авария для любой известной мне ФС, если не было избыточности на другом девайсе. А если кому это не нравится, нехай UPS юзает или ноут с батарейкой дескать. Ну вот такая вот оптимизация - фирмвара живет своей жизнью и может иметь свою линию поведения. И даже профакать данные если вы нарушили протокол взаимодействия. Который вот такой - вы явно уведомляете накопитель о намерении снять питание и только посое этого имеете право питание снять. Это часть спеков стандартов. Если вы это не обеспечили, это вообще-то ваш факап, так то. И там один большой UNDEFINED что случится. Но, вот, этому экспонату 107 раз повезло. Однако вы же понимаете что это без гарантий? И если на 108 раз он пролюбит большой сегмент и фс развалится - ну, окей, у SSD есть некоторые специфичные особенности, не очень приятные с точки зрения файлух. Это частично касается и "черепицы".
	Ответить | Правка | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (425), 27-Май-23, 20:23
	Если только самому собирать kernel и добовлять пач чтобы работал riser5, а это вариант не для всех. И то это, чтобы попробовать и решить riser5 усраивает или нет.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	182. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (425), 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ообщить модератору

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

	353. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (352), 01-Июн-23, 05:55
	И отдать или продать тому у кого есть желание или заинтересованность и ресурс этим заниматься.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 01-Июн-23, 08:36
	Эдуард Шишкин и хочет, и развивает свою ФС, когда находит на то время. И даже в последнем интервью приглашал желающих писать код под его руководством - оно не для всех понятно выглядело, поскольку платить за работу он готов в основном знаниями.
	Ответить | Правка | К родителю #352 | Наверх | Cообщить модератору

	378. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (378), 01-Июн-23, 20:43
	Сам собери Kernel с патчем для работы Reser5 вариант не устраивающий многих, так в массы её не продвинуть, уже писал об этом. И не факт, что Reser5 будет востребована или популярна. А так да я знаю, что он не забросил файловую систему так как для новых Kernel выпускает патч.
	Ответить | Правка | Наверх | Cообщить модератору

	384. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 02-Июн-23, 03:37
	> Эдуард Шишкин и хочет, и развивает свою ФС, когда находит на то время. Когда он на btrfs плевался - его общий decision making зарекомендовал себя сильно хуже. Гражданин упирался в перфекционизм в 1 частном случае, который не сильно мешает жить в реальных кейсах, > И даже в последнем интервью приглашал желающих писать код под > его руководством - оно не для всех понятно выглядело, поскольку платить > за работу он готов в основном знаниями. У него самого нет знаний как делать большие проекты. И как взаимодействовать с ядерщиками чтобы это в майнлайн приняли - тоже. Да и идеи относительно практической эксплуатации ФС, возникающих при этом вызовов и траблов у него какие-то сферисеско-вакуумные. Чтобы решать проблему ее сперва хотя-бы осознать надо. Для файлух это очень сложный топик. Особенно для некстген дизайнов. Чтобы сделать btrfs должен был случиться zfs, и на основе его проблем (главная из которых имхо тормоза и ресурсожоркость без подпора такого дизайна ломовыми кешами). Чтобы Кент попробовал bcachefs должен был случиться btrfs, собравший грабли такого дизайна в реальных продакшнах оптом. И вот тогда станет понятно куда двигать дальше. Если кто хочет посмотреть на более правильный формат разработки nextgen nextgen'а, могу показать кой-что интересное https://lore.kernel.org/lkml/20230509165657.1735798-1-kent.o.../ Заметьте: хотя Кента в энный момент один аспект достал, и он откоментил от души, в целом там очень милое и конструктивное взаимодействие. Когда люди сообща решают проблемы, сообща factor out реюзабельные куски, для ВСЕХ, и проч. А не просто встают в позу как Шишкин. И вот поэтому я думаю что у Кента - получится. И у нас будет +1 файлуха. Крутая и интересная. Но если так заметить, там вон народ уже грабель откушал при попытке тестануть ФС. Даже не на уровне ФС - а на уровне сетапа виртуалки которую скриптик хотел. Вот так вот вы даете свой код другим - и узнаете много нового. Об ожиданиях, требованиях, траблах и проч. Шишкин оказался совершенно не готов столкнуться с реальным миром в этих аспектах. И пусть он хоть нобелевский лауреат при этом, толку то.
	Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

	389. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от n00by (ok), 02-Июн-23, 09:08
	> У него самого нет знаний как делать большие проекты. ФС и не должна быть большим проектом. Программисты на баш и мастера копипасты там не нужны. > И как взаимодействовать > с ядерщиками чтобы это в майнлайн приняли - тоже. Он выполнил все требования. Отказ ему политически мотивирован, как и в случаях с Байкал и муражирование с NTFS.
	Ответить | Правка | Наверх | Cообщить модератору

	397. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 18:57
	> ФС и не должна быть большим проектом. Теоретически, да: все мы хотим маленький, шустрый, стабильный, фичастый дизайн/код и отсутствие багов. Практически, взаимоисключающие параграфы, так только FAT, с фичностью и перфомансом швах. В полной имплементации с LFN, субдиалектами и проч даже FAT не оч простой. А еще экстентики, быстрый индекс дир, сжатие, cow, управление томами в удобном виде... а теперь со всей этой фигней мы попробуем взлететь! При попытке это сделать узнаете что железо работает не так как вы себе представляли, юзеры используют ФС иначе чем вы думали, а еще интеграция с кернелом может врезать пинка. Но вы можете обойтись именами 8.3, без сжатия, снапшотов, рефлинков, экстентов и удобного управления томами. В DOS обходились же. > Программисты на баш и мастера копипасты там не нужны. Глядя на опыт разработки файлух в кернеле позволю себе с этим не согласиться. Так можно сделать примитивный диалект фат, 1 конкретного субдиалекта с минимумом фич. А скоростной дизайн с продвинутыми фичами - фиг. Архитект может накидать core дизайна, это его вызов - только у него есть big pic. Но до ума довести, прикрутить к кернелу и его подсистемам, оптимизнуть перфоманс, выловить все баги и проч в 1 морду? Не очень реалистично, извините. К тому же железки и юзеры будут делать совсем не то что вы себе вообразили. И совсем не факт что с учетом этого ваш дизайн удачен. Но вы об этом можете узнать только взаимодействуя с толпой другого народа. Без этого сферический дизайн в вакууме, летать не будет. > Он выполнил все требования. Отказ ему политически мотивирован, У меня иные идеи на этот счет. Человек почему-то решил что лучше всех все знает. А это не так. Кроме его соображений есть множество других. Code reuse, complexity management в кернеле. Если нечто можно сделать реюзабельно, это нужно сделать реюзабельно. Если в ядре есть фича, ее надо поюзать а не переть дубль. Или ваша реализация лучше, втянуть ее кернел и помочь другим caller перейти на нее. И так далее. Это издержки большого проекта, damage control для выживания. И это дело каждого участника. Никому не позволят утяжелять код и нагружать других без заботы о минимизации негативных эффектов на окружающих. Шишкин не понимает эти концепции и управление большими проектами вообще. На стыке этого всего полезны и вон те, которые вытопчут поляну, соберут грабли и проч. Потому что сразу без багов продвинутый дизайн у вас не будет. А железо и юзеры делают совсем не то что шишкин себе вообразил. > как и в случаях с Байкал Это была не лучшая страница истории, но по моему отказ пересмотрели? В конце концов драйвер - для типовой IP от synopsis чтоли, вообще. > и муражирование с NTFS. Этот нтфс, внезапно, в майнлайне. И я им даже немного пользовался. Но NTFS как технология мне не интересен, так что в отличие от btrfs я не могу похвастать чем-то полезным. А так если кто думает что NTFS был такой особенный, вот bcachefs. И даже недовольные коменты автора. https://lore.kernel.org/lkml/20230509165657.1735798-1-kent.o.../ - но заметьте, несмотря на матюки кодера, в целом кодер понимает что ядро это как межгалактический крейсер, вы не просто приносите свой блок, его еще надо заинтерфейсить и интегрировать в это все. И кстати bcachefs это как раз "лайт версия" btrfs/zfs. Но поверьте, оно относительно мелкое и простое пока это прототип у архитекта. А через 10 лет после интеграции в майнлайн, после интенсивной эксплуатации... если доживем, вернемся к этому :). Тем не менее - с учетом грабель вон тех кент сделал определенные выводы. Поэтому смог проще и быстрее. И тем не менее, если почитать дискуссию, Кент предусмотрел далеко не все, особенности кернела как большого проекта ему икнулись. Но его дискуссия мощная и конструктивная. Думаю что он при должном упрямстве пройдет квест. Он уже близок. И тут в отличие от NTFS я буду весьма заинтересован погонять этот дизайн и собрать все мыслимые грабли. Нет, вне майнлайна я это делать не буду: с одной стороны сильно менее интересно для эксплуатации, с другой, больше возни по интеграции свалится на меня. Я буду рассматривать принятие в майнлайн как тест серьезности намерений и способности к адаптиву под неидеальный мир. Кстати вотпрямща кент узнал почему "premature optimization is a root of all evil". Вооон там он с W^X столкнулся, хы. И кстати интереснейшая дискуссия на тему того как в кернеле балансируются интересы разных сторон. Если вы думали что сможете вывалить им на голову абы что, у них иные идеи на этот счет.
	Ответить | Правка | Наверх | Cообщить модератору

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

	177. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+1 +/–
	Сообщение от Аноним (425), 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. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 30-Май-23, 00:10
	Не точно написано. Надо так. Ext2 и jfs? Я не шучу.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	374. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 19:33
	Рассматривать ещё надо как исправляется файловая система. Как я вижу для jfs после выключения или перезагрузки через обесточивание автоматически всегда запускается проверка файловой системы с следующим включением компьютера. Я не сразу это понял по этому проверял через загрузочный диск Gparted. Смотрю, оцениваю, решаю использовать или нет jfs, продолжаю использую jfs. GParted 1.5.0 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.5 ======================================== Устройство:    /dev/nvme0n1 Модель:    ORCL-VBOX-NVME-VER12 Серийный номер:     Размер сектора:    512 Всего секторов:    6165626 Головок:    255 Секторов на дорожку:    2 Цилиндров:    12089 Таблица разделов:    msdos Раздел    Тип    Начало    Конец    Флаги    Имя раздела    Файловая система    Метка    Точка монтирования /dev/nvme0n1p1    Первичный    2048    6164479    swap        linux-swap    SWAP     ======================================== Устройство:    /dev/sda Модель:    VBOX HARDDISK Серийный номер:     Размер сектора:    512 Всего секторов:    20971520 Головок:    255 Секторов на дорожку:    2 Цилиндров:    41120 Таблица разделов:    msdos Раздел    Тип    Начало    Конец    Флаги    Имя раздела    Файловая система    Метка    Точка монтирования /dev/sda1    Первичный    2048    20971519            ext2    EXT2     ======================================== Устройство:    /dev/sdb Модель:    VBOX HARDDISK Серийный номер:     Размер сектора:    512 Всего секторов:    41943040 Головок:    255 Секторов на дорожку:    2 Цилиндров:    82241 Таблица разделов:    msdos Раздел    Тип    Начало    Конец    Флаги    Имя раздела    Файловая система    Метка    Точка монтирования /dev/sdb1    Первичный    2048    1050623    boot        ext2         /dev/sdb2    Первичный    1050624    41943039            jfs         ======================================== Проверить на наличие ошибок и восстановить файловую систему (ext2) на /dev/sdb1  00:00:01    ( УСПЕШНО )           калибровка /dev/sdb1  00:00:01    ( УСПЕШНО )           путь: /dev/sdb1 (раздел) начало: 2048 конец: 1050623 размер: 1048576 (512.00 МиБ) проверить на ошибки файловую систему /dev/sdb1 и устранить их, если это возможно  00:00:00    ( УСПЕШНО )           e2fsck -f -y -v -C 0 '/dev/sdb1'  00:00:00    ( УСПЕШНО )           Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information 329 inodes used (1.00%, out of 32768) 18 non-contiguous files (5.5%) 1 non-contiguous directory (0.3%) # of inodes with ind/dind/tind blocks: 19/9/0 121242 blocks used (92.50%, out of 131072) 0 bad blocks 1 large file 310 regular files 6 directories 0 character device files 0 block device files 0 fifos 0 links 4 symbolic links (4 fast symbolic links) 0 sockets ------------ 320 files e2fsck 1.47.0 (5-Feb-2023) увеличить размер файловой системы, заполнив весь раздел  00:00:00    ( УСПЕШНО )           resize2fs -p '/dev/sdb1'  00:00:00    ( УСПЕШНО )           resize2fs 1.47.0 (5-Feb-2023) The filesystem is already 131072 (4k) blocks long. Nothing to do! ======================================== Проверить на наличие ошибок и восстановить файловую систему (jfs) на /dev/sdb2  00:02:10    ( УСПЕШНО )           калибровка /dev/sdb2  00:00:01    ( УСПЕШНО )           путь: /dev/sdb2 (раздел) начало: 1050624 конец: 41943039 размер: 40892416 (19.50 ГиБ) проверить на ошибки файловую систему /dev/sdb2 и устранить их, если это возможно  00:02:09    ( УСПЕШНО )           jfs_fsck -f '/dev/sdb2'  00:02:09    ( УСПЕШНО )           jfs_fsck version 1.1.15, 04-Mar-2011 processing started: 4/25/2023 12:31:24 The current device is: /dev/sdb2 Block size in bytes: 4096 Filesystem size in blocks: 5111552 **Phase 0 - Replay Journal Log logredo failed (rc=-274). fsck continuing. **Phase 1 - Check Blocks, Files/Directories, and Directory Entries **Phase 2 - Count links Incorrect link counts have been detected. Will correct. **Phase 3 - Duplicate Block Rescan and Directory Connectedness **Phase 4 - Report Problems File system object DF467942 is linked as: /home/name/.config/vivaldi-snapshot/Default/Service Worker/CacheStorage/379f1cbab5b08b6fc9e08681e42d8be311441c88 Errors detected in Directory Index Table. Will Fix. **Phase 5 - Check Connectivity **Phase 6 - Perform Approved Corrections **Phase 7 - Rebuild File/Directory Allocation Maps **Phase 8 - Rebuild Disk Allocation Maps **Phase 9 - Reformat File System Log 20446208 kilobytes total disk space. 160843 kilobytes in 43895 directories. 13469083 kilobytes in 462646 user files. 16 kilobytes in extended attributes 526984 kilobytes reserved for system use. 6610968 kilobytes are available for use. Filesystem is clean. увеличить размер файловой системы, заполнив весь раздел  00:00:00    ( УСПЕШНО )           mkdir -v /tmp/gparted-YLtEoO  00:00:00    ( УСПЕШНО )           Создан каталог /tmp/gparted-YLtEoO mount -v -t jfs '/dev/sdb2' '/tmp/gparted-YLtEoO'  00:00:00    ( УСПЕШНО )           mount: /dev/sdb2 mounted on /tmp/gparted-YLtEoO. mount -v -t jfs -o remount,resize '/dev/sdb2' '/tmp/gparted-YLtEoO'  00:00:00    ( УСПЕШНО )           mount: /dev/sdb2 mounted on /tmp/gparted-YLtEoO. umount -v '/tmp/gparted-YLtEoO'  00:00:00    ( УСПЕШНО )           umount: /tmp/gparted-YLtEoO unmounted rmdir -v /tmp/gparted-YLtEoO  00:00:00    ( УСПЕШНО )           Удалён каталог /tmp/gparted-YLtEoO
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	375. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 19:37
	Я имел ввиду качество проверки.
	Ответить | Правка | Наверх | 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ообщить модератору

	354. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (352), 01-Июн-23, 06:10
	Было показано и найдено такой вид поведения в интернете. С компьютером порядок. Это визуализация с хостом Windows. До разбора в деталях дело не доходило. Поскольку я не показывал именно тем людям, что файловую систему обслуживают. И не факт, что поняли без: снимай копию с раздела и засылай нам. И цели не было уж прямо докопаться. Цель была узнать, что с этим делать. Не узнал.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (352), 01-Июн-23, 06:11
	визуализация = виртуализация
	Ответить | Правка | Наверх | Cообщить модератору

	356. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (346), 01-Июн-23, 06:29
	Варианты. Поискать, что с этим делать - ответа не нашёл. Тогда или оставить как есть и надеяться, что в последствии это не преведёт к чему то серьёзному. Или званого установить файловую систему. Попробовал что-то с этим сделать своими силами, почитал, на свой риск по запускал команды, сломал файловую систему не монтируется. Установил званого опер. систему на раздел jfs. C Ext4 похожее, но монтирется. По этому теперь так ext2 boot, / jfs. Смотрю оцениваю.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

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

	359. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (359), 01-Июн-23, 07:05
	Снимай копию с раздела это если не виртуальный диск, а так скорее всего достаточно сжать виртуальный диск и его отдать.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	385. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 02-Июн-23, 03:41
	> Снимай копию с раздела это если не виртуальный диск, а так скорее > всего достаточно сжать виртуальный диск и его отдать. Лучше man btrfs-send на тему --no-data, так оно очень сильно меньше будет, а для воспроизведения багов зачастую катит. Это send только метаданных, без самих данных файла. Это и приваси несколько улучшает, никто не прочитает ваши чаты, не упрет ваши документы, или что там у вас - будут только метаданные о них. Это _сильно_ меньше весит чтобы по сети потом слать то.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 01-Июн-23, 06:43
	Не спрашивайте, что было написано. Не помню. Запомнил еслибы к этому серьёзднее относился.
	Ответить | Правка | К родителю #340 | Наверх | 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ообщить модератору

	370. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 01-Июн-23, 17:28
	> А вот известные разработчики блочного уровня и ФС оттуда почему-то слиняли. Так, потому что редхату не нужны их разработки, а нужна работающая xfs. Кто не согласен - при помощи ноги. > - "ощущается". Свежим взглядом он пришиб несколько "привычных" проблем и я что лишний раз подтверждает что btrfs - г-но, где даже сами разработчики не могут починить проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	398. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 19:26
	> потому что редхату не нужны их разработки, а нужна работающая xfs. Кто > не согласен - при помощи ноги. Хуже от этого как видим становится в основном редхату и их кастомерам, которым то САБЖ на бошку то глюкосратисы всякие, которые при завале вообще, имхо, мало кто отскребет от асфальта. Врядли пыхтонрасские раджи сильно тебе помогут "в случае чего". > что лишний раз подтверждает что btrfs - г-но, где даже сами разработчики > не могут починить проблемы. В смысле не могут? Чинят, и я на себе ощутил как круто и компетентно это бывает, если им подыграть немного. Я в -rc со временим отловил парочку крутых экспонатов ДО того как они меня в проде огреют. Господа чинили это в темпе вальса и спасибо сказали за бисект и продвинутую диагностику, я им почти готовое решение притащил, приятное взаимодействие, опенсорс как он должен быть :) А вот что такой же хоккей получится с XFS я уже совсем не уверен. И если кто хотел сказать что там багов не бывает, САБЖ с вами не согласен. Ну нет, oneliner они запатчить могут. А зануление файлов мариновали более 10 лет, думали что все, но нет, оказалось что ЭТО даже в относительно свежих кернелах все же еще лезло, хы. Чуть не в 5.x версиях кернела, лол. Но это не страшно, кто-то уровнем с басика и в других местах нам пригодится, если редхату не надо на такого и так очередь желающих найдется, файлухи и IO сейчас горячий топик из-за скоростного IO и ноых фич :)
	Ответить | Правка | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (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 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от 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ообщить модератору

	390. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от DEF (?), 02-Июн-23, 11:29
	И чо? Где обещанные коровы и чексуммы? Их нет и не будет. Даже если и будут, то не будет менеджера томов.
	Ответить | Правка | Наверх | Cообщить модератору

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

	399. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 19:30
	> а оно надо? на высокопроизводительной фс? > завезли reflink, пока хватит, наверное :) Как мне кажется вон тот Кент им ща покажет что можно и коров научить бегать быстро :). ЧСХ bcachefs слизал основные паттерны дизайна с btrfs, только подумали как это быстрее и проще делать можно и сильно напряглись на эту тему в начальной фазе дизайна, с учетом современного IO. И да, вот что-что а чексуммы на совремненом железе никому не мешали. Потому что оно крайне хлипкое и глючное.
	Ответить | Правка | Наверх | 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ообщить модератору

	371. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 01-Июн-23, 17:32
	> так проблема-то, чья? fs, разумеется - ceph в этом режиме работает как обычная user space программа. Пишет на файловую систему штатными средствами - но много. А оно - вот!
	Ответить | Правка | Наверх | Cообщить модератору

	377. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 01-Июн-23, 20:43
	вообще-то, для ceph именно xfs считается нормальной фс. так что вопрос остаётся.
	Ответить | Правка | Наверх | Cообщить модератору

	380. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 01-Июн-23, 21:42
	> вообще-то, для ceph именно xfs считается нормальной фс. > так что вопрос остаётся. для ceph нормальной fs является raw partition, на котором формат хранения менялся уже то ли трижды, то ли хз сколько раз. (Поэтому ни о какой нормальности речи, конечно, не идет, но тамошние проблемы целиком на совести самого ceph) Только в этом варианте его и тестируют разработчики, все остальное - легаси нулевых годов, давно заброшенное. Что в общем логично, block store бессмысленно класть поверх файловой системы.
	Ответить | Правка | Наверх | Cообщить модератору

	386. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от gleb (?), 02-Июн-23, 05:23
	>для ceph нормальной fs является raw partition *я* спорить не буду, но нагугливаемая документация так не считает. > Что в общем логично, block store бессмысленно класть поверх файловой системы. ох, сей мёд бы да Synology в уши.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	372. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 01-Июн-23, 17:34
	> За ext4 такого не замечено. тобой - незамечено, потому что ты старательно смотришь в другую сторону. Гуглить ext4 silent filesystem corruption - но это не тебе, тебе в аптеку, за вазелином. > Мне видится что это аргумент и что xfs ещё требует доводки до > стабильного состояния. не требует. П-ц стабилен. Но в ext4 тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	413. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 04-Июн-23, 01:41
	> не требует. П-ц стабилен. Но в ext4 тоже. Да, ПЦ - стабилен. Особенно с версиями кернелов в сабже. Но зачем тебе ПЦ? Неужто у тебя его еще мало? Погодь, скоро будет больше и не факт что от редхата.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от 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ообщить модератору

	409. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 04-Июн-23, 01:02
	> На 4.19 прекрасно себя чухает. Нет проблем,проста и надежна. Законы Мерфи гласят что "если вам кажется что дела идут хорошо, вы просто не заметили что-то" :). Он к тому моменту уже достаточно юзабелен было вроде по минимиуму, но например у этой версии вроде еще не было Global Reserve, специального резерва позволяющего стереть файл - даже если для этого надо добавить метаданных - а места уже нет - ухтыблин! Это довольно обидная ситуация так то, а в случае глобального резерва - если все остальное не получилось, будет временно использовано место в этом неприкосновенном запасе, и операция удаления файла прокатит. А после этого уже можно и место почистить более классическими способами. Более подробная и точная разблюдовка - на вике и readthedocs файлухи.
	Ответить | Правка | Наверх | Cообщить модератору

64. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+6 +/–
Сообщение от 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ообщить модератору

	410. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 04-Июн-23, 01:04
	> Вот это рили дерьмо. Подтверждаю - рекаверил убиты в хлам нтфсы юзерам у которых все прекрасно работало до момента когда ВНЕЗАПНО развалилось вдрызг и перестало маунтиться. В основном это из-за сбойной оперативы. Но чексуммы и такое хайлайтят, потому что в таком случае несовпадения периодически лезут и это заметно.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+3 +/–
	Сообщение от 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ообщить модератору

	400. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (400), 03-Июн-23, 19:38
	> а где храним эти контрольные суммы? и в каком количестве? Ну вот в файлухе например можно, если это не блочный а "файловый" дизайн был. В количестве копий блока разумеется - если это нечто типа RAID1. А что, чексуммы мало места vs блок занимают, оверхеда не так уж много, ценой очень скромного оверхеда знаем какая копия верная и возможности (авто)рекавери сильно возрастают. Для штук типа RAID5 парити для блоков чексум можно и не хранить по математическим причинам, для блоков данных ессно чексумы надо.
	Ответить | Правка | Наверх | Cообщить модератору

	404. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Sw00p aka Jerom (?), 03-Июн-23, 21:26
	> знаем какая копия верная откуда знаем? как понять чек-сумма битая или блок данных? разве не на том же устройстве они хранятся? кто дает гарантии "небитости" чек-сумм?
	Ответить | Правка | Наверх | Cообщить модератору

	411. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (411), 04-Июн-23, 01:15
	> откуда знаем? как понять чек-сумма битая или блок данных? ИМХО пофиг: если не совпадает -> проблемная копия, просто берем из другой. И какая разница чексум в копии порушился или сам блок? Если у нас исправная копия есть, мы как раз и отрекаверим и блок и его чексум. Эта логика на имеющихся у меня текучках и сыпучках работает изумительно, круто разворачивая теорвер в совсем другую сторону. Теперь даже на 1 неидеальном девайсе я проигрываю не "когда бэд попал под что-то важное" а "когда бэды совпали так что накрыло обе копии". И выиграть в такой джекпот при относительно редких сбоях и относительно большом числе секторов не очень реально за обозримое время. ИМХО так теорвер намного прикольнее ощущается. А всего лишь критерии проигрыша немного пересмотрели. > разве не на том же устройстве они хранятся? Вот как раз и пофиг, чексумы отъехали или блок, отрекаверить из исправной версии и дело с концом. > кто дает гарантии "небитости" чек-сумм? Стопроцентные конечно только страховой полис. Но если у вас глючное железо, на фс с чексумами это как раз очень хорошо видно когда расчитаное при записи не сходится с расчитаным при чтении, так что идут матюки фс в логи - и мы знаем что железо гунявое. У меня так целая мини коллекция глюкастиков образовалась, там и флехи, и карточки, и ссд, и мамка и проц и рама и даже шнурки сата :). Шнурки кстати в смарте видно но это ж надо явно лезть туда, а тут вот готовые матюки в логах...
	Ответить | Правка | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	–2 +/–
	Сообщение от 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ообщить модератору

	401. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 19:53
	> Если у вас есть RAID, куча копий данных, да на кой хрен > вам вообще checksums? А откуда мы знаем которая из копий на райде правильная когда на отличия налетели? Ну вот для этого чексумы и надо :). Кроме того чексумы проверяют работу железа end to end. И если сбойное железо не отлавливать - оно и кучу копий может прекрасно загадить. Счет и верификация чексум выступают неплохой такой "канарейкой" сильно демаскирующей это все. > Или вы реально думаете, что домашние пользователи все побежали делать RAID и > хранить копии данных в трёх географических разделённых местах? Если нет, они тогда бегут вооон туда, в лабу по дата рекавери и облегчаются на круглые суммы, после чего те кто поумнее обычно начинают делать бэкапы, уважать райды и вообще. > 1) Все данные - это безумно важно! > 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае > атомной зимы! А прелесть btrfs как раз в том что можно заметно улучшить свойства, используя то что есть, без безумных затрат или энтерпрайзных требований. А так по жизни вовремя детектить глюки железа это очень полезная идея. Одно дело если я глюкастик в фоне заменю и другое если у меня рабочий проект развалится или глюкастик взбрыкнет в самый ответственный момент, как это по законам мерфи и случается. > Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно. В btrfs это все может быть в виде когда этим можно даже простому юзеру пользоваться и не париться. Схему DUP на ноутбучном диске вкатить - 1 команда в командлайне. Зато рандомный бэд раз в эн лет под метаданными прекрасно пережило, парировало и вместо ВНЕЗАПНОЙ переустановки оси в мыле я занимаюсь моими проектиками. Ну а с вашими технологиями я бы вместо этого полдня пыхтел с наруливанием операционки. Что занимает сильно больше времени чем 1 команду btrfs было скроить. > Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING". А таки реально - гно. Я встречал довольно много юзеров у которых ВНЕЗАПНО разлетелась файлуха до немоунтабельного состояния (чаще всего NTFS). Резко и без предупреждения. Еще вчера они свои проекты делали. Сегодня винда в бсод улетает при попытке диск прицепитьб и вообще ни 1 файла не достать. А оказывается у них там оперативочка битая, процик глюкавенький, шнурок гнилой, но они узнали об этом только когда наконец какие-то метаданные фатально накрылись и драйвер ушел в страну вечной охоты. Это кстати баг драйвера, но если вам ваш проект было надо, бодаться с сапортом майков на эту тему вам вовсе не с руки. Как и выяснять почему chkdisk это не чинит. Врядли у вас есть полгода с сапортом майков переписываться, поэтому зачастую народ юзает альтернативные планы. Так я и узнал что это бывает. Потому что внезапно, я могу и с таким подарком справиться. > *ля. Ржу. Корона не жмёт? Пока вы тупили, штуки типа btrfs сделали продвинутые фичи довольно доступными и ненапряжными. Представляете, в конце XIX века поездку на авто приходилось готовить почти как экспедицию. А в XXI веке мы просто плюхаемся в кресло и поехали. Хотя действо то же самое. И да т.к. отсутствие чексум ведет к резким развалам без предупреждения, это реально хреново. Так что имхо у того субъкта есть пойнт. Но да, я тоже испорчен btrfs. Зато, вот, мою коллекцию глюкастиков пополнил. Несколько флех, sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый проц... нормальненько так :) можно вам из этого комп свинтить, а вы и не заметите так сразу :P.
	Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

	417. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от onanim (?), 04-Июн-23, 08:45
	> Несколько флех, > sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый > проц... мне китайский переходник SATA-USB наделал в ссд кучу Uncorrectable ошибок и даже один Reallocated, и дико тормозило чтение-запись. я думал, что диск помирает, пока не попробовал другой переходник.
	Ответить | Правка | Наверх | 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ообщить модератору

	402. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 20:15
	> У f2fs была проблема с GRUB. Если создать ФС с опцией Такие проблемы бывают с много чем. С btrfs или zfs на это тоже можно нарваться. Загрузчик использует минимальную облегченную реализацию и то что она ВСЕ фичи - особенно новые - особенно в не очень свежей версии загрузчика рюхает - совсем не факт. Да даже наверное с EXT4 выпендриться можно - врядли grub умеет в fscrypt какой. Скажем, если с старым grub поюзать zstd сжатие на btrfs, он честно скажет "unknown compression" при попытке читать кернел/инитрд/что там еще. Что логично, старая версия просто не знала про такое сжатие. Но можно и не жать кернел zstd. На btrfs могут сосуществовать файлы жатые разными сжатиями и никто не обязывает жать кернел именно zstd. В лично моем случае я натыкался на куда более жирные прецеденты с f2fs - плохо к перезагрузкам и слетам питания относится, вплоть до полной кончины. В моих конфигах он вообще оказался одним из самых хлипких по этому аспекту. И так то если кто думает что это только там бывает - а вон NTFS, в современных диалектах кучу алгоритмов сжатия приделали. Старая реализация загрузчика или кого там опять же их не прожует. А может и актуальная. Полный NTFS3 конечно их рюхает. Если воооон там в конфиге кернела это включть еще специально. Как и fuse. Надеюсь это объясняет почему появился kexec(). Если кто хотел странного и продвинутого, кернел, так то, тоже бутлоадер. Крутой и мощный. С полными реализациями. Которые несколько проще до актуальных версий подтягивать.
	Ответить | Правка | К родителю #314 | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от 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ообщить модератору

	414. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (414), 04-Июн-23, 01:49
	У них вроде изначально свободное место битмапом аллокации маркировалось и потом для совместимости они так и таскали это как я понимаю. Это ж делалось в лохматые 90х. И даже если потом какие-то индексы для более быстрых операций навесить, это не отменит нужды жевать битмап как минимум при записях, если он все еще есть. Совсем его удалить они врядли смогут или захотят т.к. совместимость. А в битмапе метить занятые большие регионы ой как не быстро. У экстентов есть свои дурацкие стороны, но в целом это обычно работает лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	424. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 05-Июн-23, 22:20
	> У них вроде изначально свободное место битмапом аллокации маркировалось и потом для > совместимости они так и таскали это как я понимаю. Это ж > делалось в лохматые 90х. Ну и получается объединенная группа кластеров - это не экстент.В лучшем случае экстент имеет всего лишь 2 записи (основном и резервном) блоке (метаданные или таблица (дерево) размещение файлов) -с указанием это начало файла а это конец . Единый файл -да,быстро работает да,легко потерять -тоже да,чем и страдали XFS и райзер. Вот COW и добавила надежность для экстентов,но плата фрагментация,в самом худшем случае  таблица экстентов приближаеться к карте битманов......
	Ответить | Правка | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Аноним (324), 31-Май-23, 01:55
	Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка и папка это одна директория, открывающие случайные данные? Это та фс, где нет нормальных симлинков? Которая поддерживается примерно нигде (несколько кривых версий в винде, несколько кривых версий в линухе)? Эта та самая одна из медлительнейших ФС? Ну если она просто работает, то любая из ФС покажется вам вершиной технологий.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

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

	403. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 03-Июн-23, 20:30
	> Сейчас с 64 мгб кэша на жестких любая фс при резком выключение > может сказать -да ну его на "буй". Вообще-то нет. Там есть команды для предсказуемой работы с кешированием и информирование хоста о фактическом завершении записи. И только после этого файлуха маркирует вон то как записаное а до этого оно считается "in flight" и на это нельзя уповать для критичных нужд. Более того - в RAM хоста еще и не такой буфер и при слете питания или внезапном ребуте ТАМ пролюбится еще и не столько. Если fsync не делать, например. Самое интересное что даже чисто апликушный софт не может игнорить этот аспект под страхом мощной потери данных. Поэтому есть характерная семантика, а девайсы должны следовать определенным требованиям в реализации кеширования. Иначе файлухи имеют полное право неконтролируемо развалиться. На слет произвольных 64 мегов в любом месте никто корректно не реагирует. Если вы потеряете большой кус допустим метаданных - это достаточно критично. > Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы. Это происходит потому что файлуха не журналила данные файла, инфо для undo/redo хватало только на метаданные и консистентность вида ФС в лучшем случае, а что там стало с файлом внутри - это очень отдельный вопрос. Потому и битый. Не будет произвольно взятая программа жрать наполовину старый, наполовину новый файл. А у виндовых ФС как я понимаю и оглавление диры иногда может пострадать, так что часть файлов оказывается как бы на месте, но как бы безымянными - потому что их дира разнесена вдрызг тем разлетом. Так что фс знает что аллокации есть но не знает как это называлось и где лежало, например. > И симлинки и хардлинки данная фс поддерживает, софт не поддерживал, вот в этом беда. От софта по логике вещей никакой особой поддержки и не надо в простых случаях. > буквой обозначать (кроме диска с). А у ядра NT унутрях вообще сильно другие пути так-то. Но вот совместимость... > И не особо она медлительная-замечательно тюненгуеться, Не выдерживает никакого сравнения с современными файлухами. Скиньте 50K-100К файлов в диру, ребутанитесь чтобы кеш очистить. А теперь попробуйте в эту диру на холодненькую зайти. И как вам времена чтения оглавления такой диры, хоть в какой проге?! Не нравится эксплорер, можно фар, или что там еще - на результат не влияет. А теперь то же самое в линухе с какойнить иной фс. Ну там btrfs, ext4, etc. Почему там времена сильно более культурные? И тот же миднайт за весьма обозримое время это отрисовывает вот. > если стальные яйца можно даже журнал отключить. Никак не поможет при чтении списка 50К файлов на холодную. Вот и потюниговали :) > А с коммерческими драйверами спокойно под линь и 60 мгб выжимали. Под линь сейчас NTFS3 есть. Это как раз бывший коммерческий драйвер парагона как я понимаю. Ну а что, похвально, все бы так.
	Ответить | Правка | Наверх | Cообщить модератору

	423. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 05-Июн-23, 22:02
	>Вообще-то нет. Там есть команды для предсказуемой работы с кешированием и информирование хоста о фактическом завершении записи. То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать (1,5 года назад). Есть команды но нет гарантии  что эти команды выполнены- очень разработчики ext4 с этим мучились, особенно на ноутбучных винтах был этот гемморой. Сейчас просто производителей жестких -на пальцах можно посчитать, но все равно глюки случаются,особенно с флэш дисками , а про аппаратное стирание на флэшках и говорить нечего.
	Ответить | Правка | Наверх | Cообщить модератору

	426. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 06-Июн-23, 00:42
	> То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать > (1,5 года назад). Есть команды но нет гарантии Да, вы знаете, фирмвары у девайсов бывают забагованые и кривые. Но это баг и нарушение спеков стандарта - и в этом случае предъявлять что либо ядру, фс и проч не айс. Если кто купил глюкало, пусть его MFRу и пеняет. В кернеле воркэраундят популярные глюки, конечно, если это возможно, по мере возможности - потому что работать приходится в идеальном мире, в том числе и на откровенно гунявом железе с индусскими фирмварами. Они вон даже спектры у процов заворкэраундили. Но тут стоит понимать что воркэраунд в ядре - не решает проблему нарушения девайсом семантики на которую файлухи закладывались. Практически все ФС при журналинге и проч уповают на то что вон те операции с сбросом кеша - работают. Если это не так, крахи и слет питания ведут к UNDEFINE с практически любой ФС. Что там дальше будет - да что угодно в принципе. Это факап за пределами допущений ФС. Против лома нет приема. > что эти команды выполнены- очень разработчики ext4 с этим мучились, особенно на ноутбучных > винтах был этот гемморой. Сейчас просто производителей жестких -на пальцах можно > посчитать, но все равно глюки случаются,особенно с флэш дисками , Более того - такие приколы и у SD-card были. Нокия в свое время агресивно снимала питание с карт после команды шатдауна, как по спекам писано. И тут оказалось что как минимум Transcend спекам не соответствует и - отлично разлетается если так делать. И пришлось им ажно слать патчи в mmc подсистему ядра. > а про аппаратное стирание на флэшках и говорить нечего. Там максимальное время операций трекается машиной состояний и больше чем в спеках не будет, как максимум erase/program error в статусе чипа будет. Но пока до этого всего дойдет, там еще чертова куча кода фирмвары писаной хзкем. И у нее могли быть какие-то сильно свои идеи. Как показал пример допустим самса с EVO, иногда эти идеи бывают странные и они вот например TRIM нормално не смогли в некоторых девайсах, да так что девайс чуть не харакири себе делает с определенными сочетаниями запросов. Пришлось и это воркэраундить, заведя список гамняшек, с точностью до девайса и версии FW, их quirks, и явно избегать проблемные операции для таких. У особо голимых флешастых устройств может FTL вообще в такой ситуации развалиться - и тут вообще ничего вы не сделаете, там вместо данных их нарезка на полосочки из стоража идет. Это уже только специализированая лаба смогет прочитать вообще. И все же, по спекам так быть не должно. И ФС пишутся все же с опорой на эти спеки. Потому что ВСЕ мыслимые глюки ВСЕХ девайсов учесть на фазе дизайна не получится. А дальше уж пытаться воркэраундить в меру талантов. И вот тут оно может прокатить а может и нет. Разумеется новый дизайн на этапе проектирования может пытаться учесть траблы предшественников, но на 100% это нереально.
	Ответить | Правка | Наверх | Cообщить модератору

	428. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от maximnik0 (?), 06-Июн-23, 13:45
	>Против лома нет приема. Не знаю как в 10,не пробывал,а в старых версиях офтопика в настройках управления накопителя была опция запрета использования дискового кэша для записи. Там еще можно было другие алгоритмы кэширования сменить.Правда на скорости под офтопик это сказывается ощутимо, может из-за этого ходят байки о слишком сильной тормознутостьи ntfs, потому что драйвера (иногда биос) ряд чипов обнаружив ошибки записи принудительно отключали кэш на запись,и в некоторых случаях DMA доступ.(я знаю что с мелкими файлами в одном каталоге ext поведет себя гораздо лучше,но все равно если кэш пуст и она тупить будет).В linux тоже у hdparm была опция для отключения кэша диска для записи, так что не все так фатально.
	Ответить | Правка | Наверх | Cообщить модератору

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

	405. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (373), 04-Июн-23, 00:01
	> Вы путаете ФС и ОС. В NTFS это разные директории. В NTFS > даже 0 (байт значения 0) может быть в середине имени. Зато удачи там создать файл с именем "С:\CON", как минимум через WinAPI. А в линухе это валидное имя файла. И что-то мне кажется что 0x0 в человекочитаемых вещах встречается сильно реже чем ":" или "\" например. И тут еще можно поспорить насколько все это именно фичи. Ничерта не подозревающий софт будет довольно интересно реагировать что на C:\ что на 0x0, 0xd, 0xa, "|" и все такое прочее. Можно даже пробовать атаки в архивах, скажем файло "C:\WINDOWS\TROLOLO.DLL" - это всего лишь файл. В топе иерархии. Если в терминах *никса. Зато если его попробовать втрамбовать на винде "как есть" может выйти интересно. Аналогично с \..\..\..\..\windows\wtf.dll каким-нибудь. Для линукса вон то тоже валидное имя файла. В топе плоской иерархии. И кстати исторически это юзерам винды икаолсь, через тот же гит допустим.
	Ответить | Правка | Наверх | 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ообщить модератору

	406. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (346), 04-Июн-23, 00:07
	> Наоборот, у нас полка не позволяет создать один том больше 18 терабайт. Фэйсбук с базой сносившей когда-то крышу btrfs где-то на примерно 20-м терабайте - смотрит на тебя как на нуба с локалхостом. Правда, такие базы только у них и были - они и собрали такой чудесатый баг. Остальных не покусывал, полки у вас маловаты для современных тараканов.
	Ответить | Правка | Наверх | Cообщить модератору

	422. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 05-Июн-23, 11:47
	Я не раб фейсбука, и мне совершенно наплевать что они там у себя нах...евертили и какие у них от этого возникли проблемы. Судя по тому шлаку что от них идет в опенсорс (я про мертворожденный клон hg и прочие выс..ры такого же рода неспособные даже запуститься) - там все очень и очень плохо даже с поправками на то что их методы в принципе малопригодны для нормальных людей. Так вот нормальным - незачем создавать мегафс на 24 тера одним томом и рисковать потом это все в лучшем случае медленно и печально восстанавливать, если есть откуда.
	Ответить | Правка | Наверх | 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 всплыла проблема, приводящая к повреждению ..."	+4 +/–
	Сообщение от пох. (?), 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 всплыла проблема, приводящая к повреждению ..."	+2 +/–
	Сообщение от пох. (?), 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ообщить модератору

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

	407. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (373), 04-Июн-23, 00:20
	> Сколько раз пробовал ставить лоу латенси ядра - никакого эффекта нигде не > ощутил, даже измеримого Это в основном под нагрузкой ощущается. Под тяжелым IO и тому подобным. Если вы это не делаете то и разницы не будет особой. Технически есть довольно большая разница: вырубить по линии кернела длинный синхронный сискол в середине и потом доделать, временно свалив в другую задачу, или до упора динамить всех в шедулере пока он не закруглится - для неспешного IO может занять энное время, а таск при этом uninterruptable и пусть весь мир подождет. Такая вот многозадачность - подождите пока вон те тормозное IO доделают, потом задачу переключим. Это хреново если реальное время и низкая латенси интересовали, поэтому в -RT или Dynamic Preempt ядрах разрешили переключать задачи и в случае если оно долго в сисколах отвисает, вырубая это на стороне ядра. Потому и preempt - это про возможность преемптнуть начинку ядра, если стало надо. Это не совсем халявно и теряет пару процентов производительности системы, в обмен на заметно более низкий латенси под нагрузкой. В самых новых ядрах типа 6.2-6.3 понятие реалтайма сильно поменялось - там вообще пытаются сделать "жесткие" гарантии поведения на манер RTOS, внедряя патчи RT_LINUX. И когда это доделают оно вообще будет RTOS. Но за вот тот реалтайм уже приличная цена в виде оверхеда. Зато он гарантированный - это конечно не столько десктопам надо, там юзер накрайняк и подождет, сколько управляющим системам и эмбедовке (управляемый промкомпьбтером процесс в реальном мире ждать никого не будет, нет в реальном мире паузы). И тут мы уже постепенно сможем сказать привет QNX и VxWorks у которых иные идеи насчет реалтайма. Но тут стоит понимать что соответствие жесткому реалтайму это очень комплексное мероприятие и совсем не факт что вы СТОЛЬКО счастья хотели. Это уже в т.ч. ценой приличного оверхеда, если так надо для обеспечения гарантий.
	Ответить | Правка | Наверх | Cообщить модератору

	381. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 01-Июн-23, 21:51
	> Видите ли обычные ядра - для серверов и они bulk performance ценят > выше чем латенси. А вот юзер ожидающий переключения задачи или что сервер, перестающий обрабатывать запросы потому что очень занят сбросом буферов на диски - немного так себе сервер. Независимо от bulk performance самой этой операции.
	Ответить | Правка | К родителю #303 | Наверх | Cообщить модератору

	408. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (414), 04-Июн-23, 00:28
	> сервер, перестающий обрабатывать запросы потому что очень занят сбросом буферов на диски > - немного так себе сервер. Да как тебе сказать? Если сервак протупит 500 мс с запросом по HTTP ты можешь особо и не заметить. А если твой десктоп будет дергаться по 500 мс с реакцией на мыша и клаву, беситься ты будешь неимоверно, имхо. А вон тем, compute only которые получают батч на счет, потом цать минут его жуют и проч, вообще плюс-минус 5 секунд клина - ни о чем. А 5% перфоманса не лишние. Юзер же не смотрит на это все, оно там каким-то диспетчером очереди раскидывается, он программа, ему пофиг. > Независимо от bulk performance самой этой операции. Тем не менее, ряд дистров по дефолту вкатывают ядра оптимизированые на бенчи а не юзер экспериенс. А юзерам нехило понимать что UX и маркетинг с бенчами 2 большие разницы :). Туда же и космонавтов от интеля с их рекламой и фейковым TDP и нанометрами.
	Ответить | Правка | Наверх | Cообщить модератору

	421. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от пох. (?), 05-Июн-23, 11:32
	> Да как тебе сказать? Если сервак протупит 500 мс с запросом по HTTP ты можешь особо и не > заметить. увы, у меня не финтех переводящий ресурсы в ненужные криптозакорючки, с бесконечным числом инстансов в амазон, у меня олдскул бизнес. Если сервак начнет тупить внезапно и никто не вмешается - сложится сперва сервак, а потом и весь кластер. > Тем не менее, ряд дистров по дефолту вкатывают ядра оптимизированые на бенчи а не юзер > экспериенс. к сожалению это сферические бенчи в вакууме. В результате и юзерэкспириенс дерьмо, и сервер дерьмо. Привыкайте, в копроэкономике по другому уже не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	427. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
	Сообщение от Аноним (-), 06-Июн-23, 00:58
	> увы, у меня не финтех переводящий ресурсы в ненужные криптозакорючки, с бесконечным > числом инстансов в амазон, у меня олдскул бизнес. И все же если ты мониторил когданить под нагрузкой это добро то знаешь что есть характерное распределение запросов по времени выполнения. И вопрос о том как будет выглядеть worst case. Если HTTP серв протупит даже и секунду в хучшем варианте - 1 юзер из скадем 1 000 000 будет считать сайтик немного тормознутым. Поскольку веб и так не особо скоростной и low latency, никто особо не заметит. И можно все же bulk ядра гонять без особых предъяв - они немного маскируются неидеальностями сетей, тормознутостью сайтов и проч. А если у тебя мыша словит клин на секунду, это уже будет конкретно бесить. Потому что от десктопа с нормальными обычными программами мы все же ожидаем какой-никакой интерактив. В идеале того уровня который QNX Demo Disk показывал, но за такое достаточно большой hit по перфомансу уже, увы. И вообще линь под такое сразу не делался и там довольно много что икается когда хочется реалтайм, цуко, в серьез, с _жесткими_ гарантиями годными для _реалтайм_ систем. Мне оно надо и я поэтому немного трекаю те грабли. И пока там есть весьма отличные от идеала аспекты, и их не все зарулили. Это и клинит прием оставшихся RT_LINUX патчей: оно имеет смысл только если гарантии будут реально работать. > Если сервак начнет тупить внезапно и никто не вмешается - сложится сперва > сервак, а потом и весь кластер. Так он тупить же не по "среднему" числу RPS будет а по "хучшему времени отклика". В этом случае ничего не сложится, просто у особо невезучих юзеров время выполнения запроса будет великовато. RPS при этом в целом будет вполне ок. Но вот на десктопе такой номер не очень работает. Даже если в среднем все резво пашет но раз в час на миллион-хренадцатьпервом сисколе мышу на секунду якорит - где юзеры такой десктоп видали? Это неприятно в использовании, и возможность преемптнуть кернел чтобы другие задачи выполнить даже если чье-то IO хорошо встряло очень хорошая идея так то :) > к сожалению это сферические бенчи в вакууме. В результате и юзерэкспириенс дерьмо, > и сервер дерьмо. Привыкайте, в копроэкономике по другому уже не будет. У меня были другие идеи на этот счет, я не стал прогибаться под изменчивый мир и прогнул его под себя. И теперь умею в создание правильных образов систем для себя любимого. На случай если копро ну вот не хочется. Да, я научился билдить кернелы, а заодно и познал радости взаимодействия с ядерщиками. И да это не совсем простой путь. Но вообще это прикольно. И с этим вполне реально сделать весьма годную операционку. Потому что в целом они адекватны и любят свое дело. Просто знаний не всегда и не всем хватает.
	Ответить | Правка | Наверх | Cообщить модератору

	395. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	–1 +/–
	Сообщение от Анннннно (?), 03-Июн-23, 15:29
	> разные дистрибутивы, разные относительно свежие LTS ядра, разные диски (SATA SSD и > NVMe), оперативы от 16 до 64 гб, и везде копируешь тяжёлый > файл - получаешь тормоза в гуе. https://www.opennet.me/openforum/vsluhforumID3/130607.html#322 Ссылку на *официальное* ядро 6.2.8 от *RedHat* для *CentOS-7*, или ты п***абол.
	Ответить | Правка | К родителю #284 | Наверх | 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ообщить модератору

363. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."	+/–
Сообщение от DEF (?), 01-Июн-23, 10:05
Сегодня подленько так прилетело обновление ядра в Федорку - 6.3.4
Ответить | Правка | Наверх | Cообщить модератору

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

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