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

"В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
Сообщение от opennews (??), 10-Сен-25, 22:39
Разработчики openSUSE объявили об отключении файловой системы BCacheFS в пакетах с ядром Linux. В качестве причины называется присвоение данной ФС в основном ядре статуса  внешнего сопровождения, подразумевающего прекращение приёма изменений для Bcachefs в основной состав ядра при  сохранении данной ФС в кодовой базе ядра. Своими силами разработчики openSUSE не намерены бэкпортировать в дистрибутивный пакет с ядром патчи из ветки ядра от проекта BCacheFS... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63861
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–5 +/–
Сообщение от Аноним (1), 10-Сен-25, 22:39
Вот Оверстрит и довыделывался. В отличие от ZFS, который нормально живёт себе как нормальный oot, теперь будет жить на пар^W у отхожего дома.
Ответить | Правка | Наверх | Cообщить модератору

	15. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–3 +/–
	Сообщение от Аноним (-), 11-Сен-25, 01:49
	> Вот Оверстрит и довыделывался. В отличие от ZFS, который нормально живёт > себе как нормальный oot, теперь будет жить на пар^W у отхожего дома. И в отличие от ZFS который Вася которого не выгнали на мороз, а никогда не пускали в приличные места, этот - попробовал в mess with the best. Правда, не очень успешно. За что был поперт с пантеона к Васе. Как минимум на время. Например чтобы он смог оценить как ему - отвисать с Васей на морозе. И что он потерял. И стоило ли оно того.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+5 +/–
	Сообщение от Аноним (-), 11-Сен-25, 05:44
	>Вот Оверстрит и довыделывался. В отличие от ZFS, который нормально живёт себе как нормальный oot, теперь будет жить на пар^W у отхожего дома. Не обобщай. ZFS - пермиссивка, чтобы его приняли в ядро нужно лицензию помянять на GPLv2. А авторы ZFS - бздуны, они на копилефт никогда не перейду. Автора BCacheFS поставили в угол, пусть подумает о своём поведении. Вернуться он сможет в любое время когда сам этого захочет. Когда он вернётся, над ним приставят старших товарищей, это на первых порах. Потом если его поведение будет правильным с него снимят шефство. Так сказал Линус.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	35. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от A.Stahl (ok), 11-Сен-25, 07:38
	Also sprach Linus.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (-), 11-Сен-25, 11:21
	> Не обобщай. ZFS - пермиссивка, чтобы его приняли в ядро нужно лицензию > помянять на GPLv2. Вообще-то CDDL - это копилефт. Слабый. И - назло бабушке^W Торвальдсу не совместимый с GPL. Потому что сану надо было - соляру продвигать. Как типа открытую. А тут понимаешь пингвин, в норку уволочет? Никак не можно. Жаба корп манагеров и победила здравый смысл. > А авторы ZFS - бздуны, они на копилефт никогда не перейду. Бсдшеники нынче юзают - результат ZFS On Linux. Вот такие из них разработчики ФС и всего остального. При том в лине оно как раз на вторых ролях, за GPL incompat. А BSDшники не гордые, им weak copyleft не жмет. Никогда не перейдут? :) > Автора BCacheFS поставили в угол, пусть подумает о своём поведении. Ну так он достал даже извините Bacik'а (я никогда не видел его дающим жесткие отповеди ранее) и Tso (если этот говорит вам что вы неправы, вероятно так и есть). > Вернуться он сможет в любое время когда сам этого захочет. Это уже не так. В данном случае - когда придет время. И когда он будет готов нормально взаимодействовать как взрослый человек. До этого момента сие несколько преждевременно. Как видите pull request может быть просто не выполнен если вы достали тиму и прочитали лекцию человеку который проект интегрировал. И тут вдруг оказывается - что вы чисто технически теперь сами по себе. Вам теперь и правда никто не мешает, как и хотели. Но есть нюансы.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	63. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (63), 11-Сен-25, 17:04
	> Бсдшеники нынче юзают - результат ZFS On Linux. Который на линукс передрали оттуда, откуда бсдешники. Но ослинуксоиды предпочитают об этом не вспоминать, трубя во все горла, что ZFS написан линуксоидами. Портирован "с нуля!". :) Прям как cinnamon в минте в соседней новости.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 15:44
	> Который на линукс передрали оттуда, откуда бсдешники. Ну, логично. Так что манагеры сан могут с своим CDDL делать морду официанта из анекдота "ну значит не прокатило :(". Т.е. это - анноянс и неудобства, а не "showstopper". Разница. Но потом то кому надо вокруг линуха разработку подхватили. А BSD настолько печальны что сами они вообще не могут - нихрена. Ну вот с линуха кормятся. И не только фс, дрова видях и чего там еще - тоже. В общем все идет к тому что это будет бастардизированый и извратный косплей линухкернела :) > Но ослинуксоиды предпочитают об этом не вспоминать, трубя во все горла, что ZFS > написан линуксоидами. Портирован "с нуля!". :) Я такого не утверждал, не надо мне свои комплексы неполноценности приписывать. > Прям как cinnamon в минте в соседней новости. Без понятия как это связано с сабжем.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (63), 11-Сен-25, 17:35
	> ZFS - пермиссивка, чтобы его приняли в ядро нужно лицензию > помянять на GPLv2. Была бы пермиссивка, вы бы цап-царап, как с бсд. А тут вам когти подрезали. В ядро его не принимают, благодаря вашему проприетарному патрону Ораклу, который владелец, бережёт лицензию. Понимая, что если сменить ZFS CDDL на GPL, то бронетранспортёрная фс - всё.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

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

	77. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (63), 11-Сен-25, 22:21
	> Слушай, ты прям всё выворот на выворот. BSD лицензию легко сделать проприетарной. Так сделать - не значит, что она проприетарная. Когда сделаешь, тогда это будет другая лицензия.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 18:44
	>> Слушай, ты прям всё выворот на выворот. BSD лицензию легко сделать проприетарной. > Так сделать - не значит, что она проприетарная. > Когда сделаешь, тогда это будет другая лицензия. Но в результате все это BSD превратилось в кормушку для паразитов и кидал. Всем остальным этот позор оказался нахрен не. Про все эти двойные стандарты еще Линкольн сказал: те кто хотят отобрать свободу у других - не заслуживают ее и сами. Вот эти слова да лживым проприерасам вещающим про свободы в уши.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (68), 11-Сен-25, 18:30
	>ZFS - пермиссивка, чтобы его приняли в ядро нужно лицензию помянять на GPLv2. Была бы она пермиссивка, приняли бы в ядро без вопрос, как и кучу BSD-драйверов. А она копилефт, в этом вся суть.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	70. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 18:43
	>Была бы она пермиссивка, приняли бы в ядро без вопрос Нет, не взяли бы. >А она копилефт, в этом вся суть. Её лицензия не совместима с GPLv2. Частичный копилефт = не копилефт.
	Ответить | Правка | Наверх | Cообщить модератору

3. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+3 +/–
Сообщение от Аноним (3), 10-Сен-25, 22:48
> Once the BCacheFS maintainer behaves Аж читать тошно... За ним один косяк - нарушение таймлайнов разработки ядра, когда в rc релизы залетает много кода, что вызывает регресс тестирования. А тут обиженки какие-то тем, что он коммитит и разрабатывает без уважения.
Ответить | Правка | Наверх | Cообщить модератору

	4. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от НяшМяш (ok), 10-Сен-25, 22:51
	Опять попеннетный кексперт вообще не в курсе о том, что говорит. Достаточно было даже последний тред почитать, где Кент уже был "максимально вежливый". Там другие мейнтейнеры очень много ласковых ему высказали, в том числе и с примерами. И, как человек, следивший за предыдущими конфликтами, я точно не на стороне Кента. https://lore.kernel.org/lkml/22ib5scviwwa7bqeln22w2xm3dlywc4.../
	Ответить | Правка | Наверх | Cообщить модератору

	6. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–2 +/–
	Сообщение от вымя (?), 10-Сен-25, 23:06
	Примеры там довольно странные, на мой взгляд. «Ах, как он посмелил оскорбить разработчиков btrfs критикой их детища.» Впрочем, чего ещё я должен был ожидать от людей? Они же по природе своей любят воспринимать всё персонально, такие же яжматери, только с кодом вместо детей.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+2 +/–
	Сообщение от Ананимус (?), 11-Сен-25, 01:17
	Шок-контент: если крыть ***** своих коллег по проекту, испортишь репутацию. Вот это да. Вот это открытие. Как дети малые, ей-богу.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (17), 11-Сен-25, 02:09
	quod licet Jove, non licet bove
	Ответить | Правка | Наверх | Cообщить модератору

	18. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+4 +/–
	Сообщение от Аноним (18), 11-Сен-25, 02:14
	Он никого не крыл, всё по делу говорил. Коллеги только попались тонкокожие. На западе это нормально, они тут часто такие ранимые.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	19. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 11-Сен-25, 02:22
	> тонкокожие Опять народ не тот, да что такое-то.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от нейм (?), 11-Сен-25, 08:17
	Sad but true; ты столько же сои как и не западненцы попробуй употребить, ещё и не такой истеричкой станешь (от фитоэстрогена конечно же).
	Ответить | Правка | Наверх | Cообщить модератору

	43. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 11-Сен-25, 09:57
	Это был сарказм. Очевидно, что с мейнтейнерами все в порядке, а устраивающую драмы из-за буквально чего угодно истеричку отправили в таймаут. Это же буквально тактика воспитания детей: пока пинаешь ногами папу — папа с тобой не играет. Хочешь играть — веди себя нормально.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 04:25
	> Он никого не крыл, всё по делу говорил. Коллеги только попались тонкокожие. > На западе это нормально, они тут часто такие ранимые. То ли дело Шишкин. Всем без обиняков рассказал какие все п...сы. В результате тима стала состоять из целого Шишкина. Обнаружившего что в сутках лишь 24 часа, а тратить ресурсы его гроссмейстерского величества на всякий там майнтенанс и рутину - да еще что-то новое придумывать ... ых, ых, ых, ниасилил. И теперь он вообще - нонейм без своих проектов! И вот чего он достиг? Полил всех фекальями и свалил в закат? А стоило ли оно того? И это лучше того что было - потому что что? Представим себе что Шишкина бы никогда не существовало. Кто и что потерял бы на практике? Поток эстетствований и пару набросов на вентилятор? А это точно - ужасная потеря, о которой кто-то будет горевать?
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	49. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Stellarwind (?), 11-Сен-25, 11:58
	>[оверквотинг удален] > лишь 24 часа, а тратить ресурсы его гроссмейстерского величества на всякий > там майнтенанс и рутину - да еще что-то новое придумывать ... > ых, ых, ых, ниасилил. И теперь он вообще - нонейм без > своих проектов! > И вот чего он достиг? Полил всех фекальями и свалил в закат? > А стоило ли оно того? И это лучше того что было > - потому что что? Представим себе что Шишкина бы никогда не > существовало. Кто и что потерял бы на практике? Поток эстетствований и > пару набросов на вентилятор? А это точно - ужасная потеря, о > которой кто-то будет горевать? Шишкину просто было глубоко насрать - он деньги получает не за reiser4 и пилил он его в свое удовольствие по сути. Если долго вести себя "вежливо" и не называть говно тем, что оно есть, то вы так и будете им пользоваться, просто потому что кто-то может оскорбиться.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 11-Сен-25, 13:49
	> Если долго вести себя "вежливо" и не называть говно тем, что оно есть, > то вы так и будете им пользоваться, просто потому что кто-то может > оскорбиться. А ещё можно вести себя и правда вежливо, не нападать на коллег, не уничижать их труд, и просто программировать файловую систему в рамках процесса, принятого в Linux. В Linux может быть две хорошие файловые системы с CoW, это не игра с нулевой суммой.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (60), 11-Сен-25, 15:26
	> Шишкину просто было глубоко насрать - он деньги получает не за reiser4 А зачем он тогда приперся и стал выделываться с поливанием всех вокруг? > и пилил он его в свое удовольствие по сути. Если долго > вести себя "вежливо" и не называть говно тем, что оно есть, > то вы так и будете им пользоваться, просто потому что кто-то > может оскорбиться. Видите ли в чем нюанс? 1) Мы и так будем пользоваться - этим. Потому что его величество гроссмейстер смог родить на выбор vaporware и полутруп. Ни то ни другое не является пригодным для экслуатации вообще. При этом совершенно не важно какие там у него супер-алгоритмы. 2) Linux это большой живой проект. Нельзя в 1 день все сломать и резко переделать расово верно. Даже если хочется. Даже если вроде бы и следовало. Если так сделать - миллионы, если не миллиарды людей на этом глобусе резко пролетят и будут иметь кое-что против такого общего управления проектом. Спрос родит предложение и на этом история проекта и закончится. И девелоп перехватят более разумные существа. Торвальдс в курсе и предпочитает именно этим разумным существом и быть. Так прикольнее. Так что да, Linux - такой какой есть. И практики девелопа такие как есть. Это работает, и от добра добра не ищут. Никто не будет это радикально менять. А зачем? Linux это 1 из крупнейший, крутейщих проектов в истории человечества, соревнуется он по сути только с секундной стрелкой. Остальные где-то там, на круг отстали. Только полный идиот может хотеть это все разломать во имя луны. Никакая декларируемая цель этого не стоит. Медленно, постепенно, итеративно улучшать, не более.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	59. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 11-Сен-25, 13:52
	> Он никого не крыл, всё по делу говорил. Ну и нет, там постоянно были диалоги вида - Ты процесс нарушаешь, не надо так - ЭТО ОЧЕНЬ ВАЖНО Я СЧИТАЮ ЧТО Я ПРАВ - Но тебе не дали ACK'ов, тут так не принято - ДАВАЙТЕ НЕ БУДЕМ ЭТО ОБСУЖДАТЬ Я понимаю почему с Кентом тут носятся как со священной коровой -- сюжет про одинокого непонятого гения всех был популярен, но тут буквально грустные мейнтейнеры два года страдают с истеричкой.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	24. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–1 +/–
	Сообщение от Аноним (-), 11-Сен-25, 03:46
	> Примеры там довольно странные, на мой взгляд. «Ах, как он посмелил > оскорбить разработчиков btrfs критикой их детища.» В коммерческой рекламе не называют имена конкурентов. За это можно иск схлопотать! Что намекает на уровень терпимости человечества к этой активности. Можно рассказать в рекламе чем вы ЛУЧШЕ каких-то АБСТРАКТНЫХ конкурентов. Как максимум. Кент не понял что он попытался вырасти из "гаража" в "переулке" - в взрослые отношения. Он был не готов к этому переходу. > Впрочем, чего ещё я должен был ожидать от людей? Вокруг btrfs скучковалась самя продвинутая и мощная подборка блочнофайлушников. А кент мешок гуано туда - хлобысь! Вау, все в крапинку? Ха-ха! Нюанс? Это ему от них что-то надо обычно - а не им от него. В этом смысле возникает вопрос: а точно вывалить мешок гуано как начало чата - отличная идея? Или после этого на двери появится - мордоворот, не пускающий в клуб странных типов с мешками? > Они же по природе своей любят воспринимать всё персонально, такие же яжматери, > только с кодом вместо детей. Это идет настолько далеко что для коммерческой рекламы запрещено на уровне законодательства - указывать конкретные имена конкурентов. Можно сказать что наш порошок в 2 раза лучше конкуентов. Но если брякнете в своей рекламе "Tide - отстой" - за это ваши внуки будут еще выплачивать. Независимо от того насколько хорош ваш стиральный порошок, это просто - неприемлимая в взрослых отношениях практика. И ее могут вышибить. Достаточно жестко, если так надо.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	42. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от ымнамномнам (?), 11-Сен-25, 08:58
	> В коммерческой рекламе не называют имена конкурентов. За это можно иск схлопотать! Что намекает на уровень терпимости человечества к этой активности. Можно рассказать в рекламе чем вы ЛУЧШЕ каких-то АБСТРАКТНЫХ конкурентов. Как максимум. И рекламу, в которой мальчик покупает две банки неабстрактной кока-колы, чтобы встать на них и дотянуться до кнопки с надписью "пепси", никогда не снимали, и в ООО Яблоко никогда не вставляли в свои презентации слайдов о том, что на последние версии их операционок обновляются быстрее, чем в мире конкретных андроидов.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 11:43
	> И рекламу, в которой мальчик покупает две банки неабстрактной кока-колы, чтобы встать > на них и дотянуться до кнопки с надписью "пепси", никогда не > снимали, и в ООО Яблоко никогда не вставляли в свои презентации > слайдов о том, что на последние версии их операционок обновляются быстрее, > чем в мире конкретных андроидов. Если у вас какие-то проблемы с чтением, я повторю еще раз. В лучшем случае такие вещи считаются чем-то "политически некорректным" и на грани фола. Какие-то borderline варианты, иногда, эпизодически, могут протиснуться под радарами. Но это не доказывает что сие валидно и приветствуется. Если вы отстроите вообще всю вашу рекламную кампанию на обсирании других, как это удумал Кент - знаете что? Толпа обозленных конкурентов постарается все же обеспечить вам последствия. И вероятно это у них в результате получится. И законы в целом на их стороне и такие вещи имеют свойство - выходить боком. Так что лучший совет который Кенту дали - no, you do not need to argue. You need to shut the f...k up. Here. Now. Умение вовремя заткнуться - полезный скилл, спасающий от дофига проблем, так то. Неумеючи это - можно сделать свою жизнь сложнее. На ровном месте. Просто потому что на самом деле вам никто нихрена не должен. И если вдруг кто непонятливый и все и вся считает за данность - данность может внезапно закончиться. Как вот тут. Зато лекцию Торвальдсу прочел о прожектменеджменте. Торвальдс продолжит менеджить проект как считает нужным а кент... кхе-кхе :)
	Ответить | Правка | Наверх | Cообщить модератору

	7. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (7), 10-Сен-25, 23:13
	> За ним один косяк - нарушение таймлайнов разработки ядра, когда в rc релизы залетает много кода, что вызывает регресс тестирования. Ну да, это ведь такая мелочь.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	29. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 04:35
	> Ну да, это ведь такая мелочь. Он наверное единственный файлушник который откровенно профачил RC1, вбросив здоровенный pull request в последние секунды перед самым RC1. Который оказался вообще совсем не протестирован - и сломал народу билды. Называя вещи своими именами, гражданин нехороший транслировал свою проблему неумения менеджить свое время и девелоп проекта с нормальным планированием что входит в релиз, в проблемы целой толпы никак не связанного народа, от Торвальдса до кучи васянов виноватых только тем что Кент не тестанул билдовку своего "супер" кода на их архитектуре. Так что на поверку - код оказался не такой уж и "супер". А еще так ведут себя только м...ки или долбоящеры. И обоим типам в командной разработке софта ловить нечего. Потому что за такое целая толпа ВНЕЗАПНО начинает хотеть испить крови этого счастливчика. Почему-то. Наверное, если кернел у вас совсем не собрался - не так уж важно какая офигенная там могла бы быть фс, да? :)
	Ответить | Правка | Наверх | Cообщить модератору

	71. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от User (??), 11-Сен-25, 18:52
	>> Ну да, это ведь такая мелочь. > Он наверное единственный файлушник который откровенно профачил RC1, вбросив здоровенный > pull request в последние секунды перед самым RC1. Который оказался вообще > совсем не протестирован - и сломал народу билды. Не-не-не, пжди. "профачил" или "в последнюю секунду"? Или в предпоследнюю? Или за сутки? Или за неделю? А может просто "без уважения"? Тут или вы принимаете изменения в окне приёма, не важно, в последнюю там или предпоследнюю - или корректируете процессы, а не так, что "окно приёма изменений" для приёма изменений, но изменения, поданные в рамках окна не принимаются.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (-), 11-Сен-25, 19:08
	> Тут или вы принимаете изменения в окне приёма, не важно, в последнюю там или предпоследнюю - или корректируете процессы, а не так, что "окно приёма изменений" для приёма изменений, но изменения, поданные в рамках окна не принимаются. - Маладой человек! Вы что не видите? У нас обед! -- Так тут написано.. - Так это не для вас написано! Идите, идите!
	Ответить | Правка | Наверх | Cообщить модератору

	78. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 04:09
	Опять опеннетовский кексперт пишет о том, в чем не шарит. Merge window — для мержа протестированного кода, который пишется между окнами. Кент принес жирную серию, которую только что на коленке написал и которая, разумеется, взорвалась. Еще и под конец окна.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	81. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 12:16
	> Опять опеннетовский кексперт пишет о том, в чем не шарит. Merge window > — для мержа протестированного кода, который пишется между окнами. Кент принес > жирную серию, которую только что на коленке написал и которая, разумеется, > взорвалась. Еще и под конец окна. ""окно приёма изменений" для приёма изменений, но изменения, поданные в рамках окна не принимаются."(С) Этот процесс - кого надо процесс, классовым чутьём понимать надо, ага. Как классовое чутье предлагает отличать "код написанный между окнами" от "кода, написанного во время окна"? А какие критерии оно предъявляет к "протестированности"? Нет, знаменитое "Если код собирается - то он хорош, если запускается - великолепен!" от ЛИДЕРА я помню, но может с тех пор в консерватории и поменялось чего? Мне, если что - не самому, тут один кент интересуется...
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 13:35
	В документации Linux процесс описан. Сотни других разработчиков присылают патчи, проблем нет. Я присылал патчи, проблем не было. Проблемы есть только у Кента. Это буквально тот случай, когда миллионы мух не могут ошибаться — если у нас все ок, значит Кент делает что-то не так.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 16:31
	> В документации Linux процесс описан. Сотни других разработчиков присылают патчи, проблем > нет. Я присылал патчи, проблем не было. Проблемы есть только у > Кента. Это буквально тот случай, когда миллионы мух не могут ошибаться > — если у нас все ок, значит Кент делает что-то не > так. Описан, ага. Только следуют ему ээээ... в лучшем случае - выборочно. Начиная с самого ГЛАВНОГО, что забавно. То вот платиновые вообще без ревью ломающий код мержат (Как же так же вышло-то, а?), то вот т-щ Торвальдс от г-на Кента патчи самолично в обход принимает - то "не принимает" - по цвету паспорта - и вот все примерно так. А процесс - да-да, есть. И даже описан, лучше всего - в той басне Крылова, что про очки.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 16:52
	>> В документации Linux процесс описан. Сотни других разработчиков присылают патчи, проблем >> нет. Я присылал патчи, проблем не было. Проблемы есть только у >> Кента. Это буквально тот случай, когда миллионы мух не могут ошибаться >> — если у нас все ок, значит Кент делает что-то не >> так. > Описан, ага. Только следуют ему ээээ... в лучшем случае - выборочно. Да нет, патчи проходят ревью, собираются signed-off-by от мейнтейнеров, оно мержится в дерево конкретной подсистемы, потом уходит Линусу. Все. Ничего сложного. > Начиная  с самого ГЛАВНОГО, что забавно. То вот платиновые вообще без ревью > ломающий код мержат (Как же так же вышло-то, а?), то вот > т-щ Торвальдс от г-на Кента патчи самолично в обход принимает - > то "не принимает" - по цвету паспорта - и вот все > примерно так. Т-х Торвальдс два года занимался психотерапией с Кентом, мержил его ВНЕЗАПНЫЙ код в RC и писал полные сожаления "ну пожалуймуста не надо так больше, ладно?". Сколько ещё лет т-щ Торвальдс должен быть продолжать этот блуд?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 17:31
	>Да нет, патчи проходят ревью, собираются signed-off-by от мейнтейнеров, оно мержится в дерево конкретной подсистемы, потом уходит Линусу. Все. Ничего сложного. Угу. Проходят. А некоторые - не проходят. И не уходят, кстати. Ну, кого надо патчи. Экiя, право, оказiя! /вопрос со звездочкой - а что же было изменено в процессе после обнаружения этого печального факта?/ >Т-х Торвальдс два года занимался психотерапией По нашему это называется "Т-х Торвальдс два года клал на процесс, которым он владеет/управляет".
	Ответить | Правка | Наверх | Cообщить модератору

	100. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 18:18
	> Угу. Проходят. А некоторые - не проходят. Code review сделан буквально для этого — оценить код. Исход может быть положительным, а может и не быть. > По нашему это называется "Т-х Торвальдс два года клал на процесс, которым он владеет/управляет". Какую часть процесса Линус нарушил?
	Ответить | Правка | Наверх | Cообщить модератору

	101. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 18:31
	> Какую часть процесса Линус нарушил? Начал рассказывать про "график разработки"? If bcachefs can't work sanely within the normal upstream kernel release schedule, maybe it shouldn't *be* in the normal upstream kernel. Тут или патч попал в разрешенное окно, или нет. То что он большой или маленький не должно влиять на рассмотрение.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 18:35
	>> Какую часть процесса Линус нарушил? > Начал рассказывать про "график разработки"? > If bcachefs can't work sanely within the normal upstream kernel > release schedule, maybe it shouldn't *be* in the normal upstream > kernel. > Тут или патч попал в разрешенное окно, или нет. > То что он большой или маленький не должно влиять на рассмотрение. Не, если вы считаете, что это создает проблему - вы вводите дополнительные количественные метрики. Ну-там, прием патчсетов, меняющих более чем N-файлов проходит ДО...
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 19:42
	>>> Какую часть процесса Линус нарушил? >> Начал рассказывать про "график разработки"? >> If bcachefs can't work sanely within the normal upstream kernel >> release schedule, maybe it shouldn't *be* in the normal upstream >> kernel. >> Тут или патч попал в разрешенное окно, или нет. >> То что он большой или маленький не должно влиять на рассмотрение. > Не, если вы считаете, что это создает проблему - вы вводите дополнительные > количественные метрики. Ну-там, прием патчсетов, меняющих более чем N-файлов проходит > ДО... Они сразу прописаны в гайдах. С объяснениями почему так.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	114. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 19:56
	>[оверквотинг удален] >>> Начал рассказывать про "график разработки"? >>> If bcachefs can't work sanely within the normal upstream kernel >>> release schedule, maybe it shouldn't *be* in the normal upstream >>> kernel. >>> Тут или патч попал в разрешенное окно, или нет. >>> То что он большой или маленький не должно влиять на рассмотрение. >> Не, если вы считаете, что это создает проблему - вы вводите дополнительные >> количественные метрики. Ну-там, прием патчсетов, меняющих более чем N-файлов проходит >> ДО... > Они сразу прописаны в гайдах. С объяснениями почему так. Ну так что именно Кент нарушил-то? Документ, пункт?
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	116. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 20:18
	Прислал патчи не прошедшие тестирование и без ack’ов от мейнтейнеров подсистем.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	119. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 20:30
	> Прислал патчи не прошедшие тестирование и без ack’ов от мейнтейнеров подсистем. Тю! Подишта товарищей из мелкософт за то же самое так же вот - того? Или это немножко - ну, вы знаете? Другое? И то, что раньше г-н Торвальдс эти вот патчи лично принимал - вообще третье, патамучта он же ГЛАВНЫЙ - хочет, принимает, хочет - не принимает, таков путь! - в смысле "процесс"?
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	122. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 21:23
	Кент сделал это не в первый раз. И не во второй. Он делал это два года, пока от него все не устали. У тебя не получится представить это как единичный случай, все знают, что он так делал на регулярной основе.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	126. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 21:49
	> Кент сделал это не в первый раз. И не во второй. Он > делал это два года, пока от него все не устали. У > тебя не получится представить это как единичный случай, все знают, что > он так делал на регулярной основе. Оу. Я не пытаюсь, в общем-то. Я - если вы не поняли - вообще про другое.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	127. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 22:12
	>> Кент сделал это не в первый раз. И не во второй. Он >> делал это два года, пока от него все не устали. У >> тебя не получится представить это как единичный случай, все знают, что >> он так делал на регулярной основе. > Оу. Я не пытаюсь, в общем-то. Я - если вы не поняли > - вообще про другое. Ну если ты перестанешь говоришь шарадами, тебя лучше поймут.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	105. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 18:53
	> Начал рассказывать про "график разработки"? Он не «начал рассказывать», это прописано в правилах: > A relatively straightforward discipline is followed with regard to the merging of patches for each release. At the beginning of each development cycle, the “merge window” is said to be open. At that time, code which is deemed to be sufficiently stable (and which is accepted by the development community) is merged into the mainline kernel. > Тут или патч попал в разрешенное окно, или нет. То что он большой или маленький не должно влиять на рассмотрение. Должно, потому что это буквально обговорено в их гайдах по приему патчей. Это знает любой разработчик.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 18:49
	>> Угу. Проходят. А некоторые - не проходят. > Code review сделан буквально для этого — оценить код. Исход может быть > положительным, а может и не быть. Ну, да, ну да. А потом - ой! https://www.opennet.me/opennews/art.shtml?num=62555 Вопрос со звездочкой - остается, ага.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	106. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 19:05
	Ага, и если почитать тред, все согласились что ерунда случилась и так делать не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 19:54
	> Ага, и если почитать тред, все согласились что ерунда случилась и так > делать не надо. А.тличное процессное управление, просто великолепное, чоужтам. Может даже кто-то сказал "мы больше не будем!", но это уже вряд ли, в конце-то концов - люди уважаемые, не всякие там. У вот так и принято в актах расследования писать "ерунда случилась, не надо так".
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	117. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 20:19
	Ты веруешь в идеальные процессы где никто не лажает?
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	118. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 20:27
	> Ты веруешь в идеальные процессы где никто не лажает? Уффф... Ну, т.е. как Моисей с горы Синай ПРОЦЕСС принёс - так он и идеален, да? А слово в нем изменить не моги, патамучта Б-я воля? Вот как раз по тому, что процессы не идеальны, и мир - меняется, ими надо _управлять_. И нет - "чот фигня вышла - делоите дальше хорошо, а плохо - не делоите" - это не "управление".
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	120. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 20:31
	> Вот как раз по тому, что процессы не идеальны, и мир - меняется, ими надо _управлять_. И нет - "чот фигня вышла - делоите дальше хорошо, а плохо - не делоите" - это не "управление". Ну это какие-то общие бессмысленные слова. Процесс работает когда с ним лучше, чем без него, это буквально способ упорядочить хаос. Порядок заноса патчей в ядро работает довольно неплохо, за исключением Кента.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	121. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 20:40
	>> Вот как раз по тому, что процессы не идеальны, и мир - меняется, ими надо _управлять_. И нет - "чот фигня вышла - делоите дальше хорошо, а плохо - не делоите" - это не "управление". > Ну это какие-то общие бессмысленные слова. Процесс работает когда с ним лучше, > чем без него, это буквально способ упорядочить хаос. Порядок заноса патчей > в ядро работает довольно неплохо, за исключением Кента. Ну так и запишем - "если какая-то деятельность ведется - то она a priori ведется наилучшим из всех возможных способов образом" и ничего делать-то и не надо - а если "что-то кое-где у нас порой", то "оносамодуровиновато", или - в случае кого-надо-нога просто "оно само".
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	124. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Ананимус (?), 12-Сен-25, 21:30
	Бога ради, но это ничего не поменяет.
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	125. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 21:42
	> Бога ради, но это ничего не поменяет. Ну, тут у нас консенсус.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	107. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 19:17
	> Не-не-не, пжди. "профачил" или "в последнюю секунду"? Или в предпоследнюю? Или за > сутки? Или за неделю? А может просто "без уважения"? И то и другое и можно без хлеба. 1) Есть такая штука, common sense. Он говорит что хреначить большие изменения в последний момент - поганая практика. Выходящая боком. Кент решил это узнать максимально сложным способом. 2) Если пикироваться формальностями, до буквы - в эту игру могут играть и двое. Кенту можно пришить не менее 2 дюжин нарушений CoC и уйти его на этом основании, если цель такая. Но в лине не политики а технари, они честно сказали как есть. Нельзя считать себя эксклюзивом, создавать всем кучу неудобств и быть с половиной тимы на ножах. Это неприемлимо. 3) Кстати ни 1 уважающий себя мегакорп тоже не потерпит такие релизные практики, подачу кода и отношение к коллегам. За такие фортели для начала - депремируют пару раз, неудачник получит вместо нормального дохода дежурную пайку. Чтоб совсем не сдох, типа 15% номинала (минимум указанный в контракте, остальное - бонусы, которых можно законно лишить в любой момент). Так все почему-то очень понятливые! Торвальдс не может депремировать Кента. Но может просто не выполнять его пуллреквест. Тоже довольно эффективно работает, борзоту и пофигизм лечит только в путь. 4) И кстати Торвальдс никогда на себя не брал никаких формальных обязательств всегда выполнять pull request присланные Кентом, если что. Это его проект - и его решения что туда агрегировать, а что нафиг. Кент немного не учел этот момет, пытаясь начитывать лекции. Зато теперь он сможет подумать над тем что он потерял и как оно ему - девелопаться вне майнлайна опять. На самом деле в лине - как в и приличных корпах - подразумевается работа на результат. Это то что вы никак не можете взять в толк. Да, хорошая файлуха - это прикольно. И улучшает систему. Но если это в итоге ведет к слому RC, теркам в команде и проч - не, такой ценой оно не надо. > Тут или вы принимаете изменения в окне приёма, не важно, в последнюю > там или предпоследнюю - или корректируете процессы, Вот, имхо, сделайте _ВАШ_ проект. И там рулите как сочтете нужным. А мы посмотрим куда вас это все приведет и с кем вы там конкурировать сможете. Я конечно обойду ваши проекты за пушечный выстрел. Просто потому что в ваши PMские и софтостройские скиллы я не верю от слова вообще. И лучше доверю мою тушку Торвальдсу. Потому что его релизные практики делом доказали свою эффективность и результативность. > а не так, что "окно приёма изменений" для приёма изменений, но изменения, поданные в рамках > окна не принимаются. Вот в своих проектах и показывайте как офигенно ваши суперские принципы работают на практике. А то поразвелось тут советчиков по PM'у - поди без единого персонального проекта даже, но точно уверенных что знают как надо. Я видел что у таких получается и именно поэтому предпочитаю Linux и управление проектом в стиле Торвальдса.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	111. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 19:52
	>> Не-не-не, пжди. "профачил" или "в последнюю секунду"? Или в предпоследнюю? Или за >> сутки? Или за неделю? А может просто "без уважения"? > И то и другое и можно без хлеба. > 1) Есть такая штука, common sense. Он говорит что хреначить большие изменения > в последний момент - поганая практика. Выходящая боком. Кент решил это > узнать максимально сложным способом. А! "По понятиям"(ТМ), в смысле? Ну, так бы и говорили, чо стесняться-то? Один кент "без уважения" подошел, ворЫ маляву кинули, пахан сходняк собрал - и раскороновали щегла(ТМ) - нет же, придумывают всякие там эти, как их... "процессы".
	Ответить | Правка | Наверх | Cообщить модератору

	23. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (23), 11-Сен-25, 03:31
	Так не читай! Или тоже сейчас пидали разыгрывать будешь? Ему ядро бесплатно делают, а он уже и не знает как своё ЧСВ девать.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

5. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
Сообщение от Аноним (-), 10-Сен-25, 22:56
ЧтошЪ финал слегка предсказуемый. А ведь всего-то не надо было ломать устоявшиеся процессы и лезть со своим " ̶м̶н̶е̶ ̶т̶о̶л̶ь̶к̶о̶ ̶с̶п̶р̶о̶с̶и̶т̶ь̶ мне только пофиксить" пихая новые фичи в фикс pull request'ы. Зато теперь мы сможем увидеть, как самая лучшая ФС в мире, завоюет популярность силами Сообщества™))
Ответить | Правка | Наверх | Cообщить модератору

	9. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (9), 10-Сен-25, 23:58
	>А ведь всего-то не надо было ломать устоявшиеся процессы Дело вообще не в процессах, а в том, что ФС Кента нафиг не нужна в принципе. У каждой новой ФС есть недостатки: 1. надо поддерживать 2. плодит фрагментацию Линусу BTRFS была нужна как ФС с тремя условиями: 1. invented here и под нужной лицензией, с копирайтами у нужных людей 2. nextgen Какой проект первый пообещал эксклюзивно продвигать монополию Linux - на том и женились. ZFS уже была жената на Solaris - на ней жениться не стали. Кент начал делать эксклюзив - ну его потерпели как любовницу-содержанку, при первом же недовольстве выкинули на мороз. Вот и всё тут.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+2 +/–
	Сообщение от MazikOttogi (ok), 11-Сен-25, 01:26
	В чём заключается "nextgen"?
	Ответить | Правка | Наверх | Cообщить модератору

	14. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+2 +/–
	Сообщение от Аноним (3), 11-Сен-25, 01:46
	> В чём заключается "nextgen"? Копирование при записи (хоть и есть недостаток, например, для дисков виртуальных машин, для которых можно поставить атрибут NoCow ценой контрольных сумм), сжатие, дедупликация, и, важный аспект, контрольные суммы для данных, что позволяют обнаружить скрытую порчу данных или проблемы с той же оперативкой. Стоит также упомянуть снимки, что могут пригодится для тех же ролинг дистрибутивов, без необходимости в lvm прослойке, и даже поддержка рейдов, подтомов и квот есть.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (73), 11-Сен-25, 20:27
	Увы, но в действительности это не работает. Там, где это действительно необходимо - стоит nocow. Или это медленно, либо приводит к космическому WA. Или может быть, вы докер гоняете на BTRFS без nocow? Может kvm или samba? В том виде в котором есть btrfs - мне не понятен смысл ее существования. Она отвратительна.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (75), 11-Сен-25, 21:01
	> Увы, но в действительности это не работает. Зависит от цели использования. Космический WA там будет если на нее бд с высокой нагрузкой поставить или какой-то proxmox. Из личного опыта отлично использовал на рабочем ноутбуке с nvme в 256 гб, где с ext 4 уперся бы в размер. А так, текстовые файлы хорошо жались. Дв и для qemu локалхоста также плевать на wa. > докер гоняете на BTRFS А в чем проблема то? Там качается тар и распаковываются (много файлов, не один как у qemu) Другое дело, если там будет postgress с дикой нагрузкой. > Samba Конечно! Для файловой помойки самое то. А какая фс, позволяет обнаружить silent data corruption? Я знаю только btrfs, zfs и bcachefs В ядре сейчас только btrfs. Bcachefs под вопросом.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (80), 12-Сен-25, 12:09
	Вряд-ли BTRFS можно назвать универсальной, учитывая все её ограничения. ZFS - совсем другое дело. А под какой лицензией и включена ли она в ядро - мне не важно. У нее нет конкурентов и в ближайшее десятилетие не появится. И без глупых костылей в лице nocow.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 16:09
	> Вряд-ли BTRFS можно назвать универсальной, учитывая все её ограничения. ZFS - совсем > другое дело. Все ровно наоборот. У ZFS есть по сути все траблы CoW от btrfs, плюс... 1) Не умеет nodatacow вроде бы. Так что дать thin, in place файлуху на ней - той же бд или чему - вообще так сразу не получится. 2) Управление RAM у ZFS годится только для файлопомоек, но полный бред для всего остального. 3) Стуктуры ФС древние, архаичные и довольно тормозные. Это по сути выросло из блочных дизайнов по классическим лекалам. Нмчерта интересного по перфомансу. Даже экстентов нормальных нет. 4) Я зацепил btrfs к роутеру с 64 мегами на все. Just because I can. Если ZFS такой капец универсальный - смогете так же? :) Вон то по жору RAM и перфомансу - на вид мало от EXT4 отличается. > А под какой лицензией и включена ли она в ядро - мне не важно. Синдром утенка как он есть. Однако для rootfs сие грабли с риском что отвалится. А там как раз снапшоты - самое то что надо. > И без глупых костылей в лице nocow. Ну конечно, разложить базу или что там - наделать cow фрагментов - и потом еще и дефрагера который вам тоже ни к чему - самое милое дело. Потом вылезает какой-нибудь iZEN с пулом о 3 дисках (пусть и ноутбучных) выдающих в сумме 15 мег на всю ораву - сразу видно ломовой перфоманс такого подхода :). И кстати кто сказал что у остальных от таких вещей иммунитет? Чудес не бывает, cow фрагменты может насоздавать, работает он так.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (21), 11-Сен-25, 03:18
	В том, что невозможно ответить на вопрос "сколько места свободно на диске", и, как следствие, перспектива получить нерабочую ФС, с которой невозможно удалить файлы, т.к. нет места (!). Ну и по мелочи, вроде порчи данных в разных ситуациях и посредственной производительности, особенно когда все эти новомодные фичи, ради которых она писалась, включены.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	27. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (27), 11-Сен-25, 04:16
	> В том, что невозможно ответить на вопрос "сколько места свободно на диске", Это верно для практически любой современной ФС. Сколько места свободно - абстрактно. Даже на EXT4 можно влегкую сделать... 1) например файлов с суммарным размером сильно больше sizeof(device). 2) дофига файлов с 0 размером, суммарный размер 0 но место на девайсе - кончается?! Видите, написано эн свободного места. Но можно получить что угодно, от нулевого суммарного размера файлов - ибо все ушло на метаданные - до аллокаций формально превышающих размер девайса в разы. Просто потому что этот can of worms уже открыт. Задолго до btrfs. Он лишь расширил фичи рефлинками, сжатием да схемами RAID и (потенциально) их смесью. Но ничего не поменялось. Хотя конечно вы можете FAT юзать, там нет holes - и все просто. Но эта простота - стоит денег и рушит перфоманс. Т.е. вы будете честно хранить гигабайтные блоки нулей и прочие ценные активы. > перспектива получить нерабочую ФС, с которой невозможно удалить файлы, т.к. нет места (!) Опять тут эксперты с знаниями из 2010 вылезли. У мордокниги с 2 миллларда хомяков - работает, и уж наверное нагрузка и такие ситуации у них - актуальнее чем у хом с опеннета, и ничего, живые. > Ну и по мелочи, вроде порчи данных в разных ситуациях Вообще-то как раз оно за счет чексумм - и чинит кривую копию, если есть откуда, и орет на сбойное железо на отлично. Вместо silent corruption, самого подлого и неприятного варианта - который по мере роста скоростей и хлипкости железа стал более частым гостем. > и посредственной производительности Хи-хи, я рефлинкну 3-терабайтный образ винча за несколько секунд. И смогу работать с второй "копией" независимо. Например fsck там сделав. А если не понравится как это работало - сотру и попробую еще раз. А вы можете показать как в ваших парадигмах эксперимент с пуском fsck на этом - с сохранением оригинала на случай если результат не понравился. И заодно посмотрим сколько времени это у вас занимает (перфоманс же) и сколько вам это стоит (на хранение копий).
	Ответить | Правка | Наверх | Cообщить модератору

	31. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–2 +/–
	Сообщение от Аноним (21), 11-Сен-25, 04:54
	> Сколько места свободно - абстрактно. Даже на EXT4 можно влегкую сделать... Ну вот на моих ext4 и xfs такой проблемы не возникает. > 1) например файлов с суммарным размером сильно больше sizeof(device). С хардлинками/рефлинками свободное место прекрасно вычисляется. А если вы про сжатие, то их нет у меня, и не надо. > 2) дофига файлов с 0 размером, суммарный размер 0 но место на девайсе - кончается?! В ext4 есть такая проблема, хотя на практике я ее не встречал. В отличие от. А в xfs и того нет. > У мордокниги с 2 миллларда хомяков - работает Клал я на мордокнигу, меня волнует, что и как работает лично у меня. И вот лично у меня за лет 25-30 опыта работы с Linux данные похерил именно btrfs, причем на ровном месте и безо всякой экзотики вроде raid и выключений питания. И включенные чексуммы не спасли. > Вообще-то как раз оно за счет чексумм - и чинит кривую копию Ну да, ну да. Гладко было на бумаге... > Хи-хи, я рефлинкну 3-терабайтный образ винча за несколько секунд. Ну и молодец. А мне все вот эти экзерсисы нафиг не нужны. Мне надо, чтобы в повседневной работе система не тупила и при этом работала надежно. А это не про btrfs.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (-), 11-Сен-25, 08:28
	>> Сколько места свободно - абстрактно. Даже на EXT4 можно влегкую сделать... > Ну вот на моих ext4 и xfs такой проблемы не возникает. На моих btrfs тоже, но это не означает что я при желании не смогу сделать довольно странные ситуации на них всех. На EXT4 может вообще - inode не хватить! И вот и место есть, и вообще. Но нет, новое файло вы туда не допишете. И перфоманс ext4 с разлапистой дирой с допустим порядка 50-100К файлов - бывает довольно похабный. Да еще и дира распухает. И не сдуется уже. Так что активно и долго юзаный EXT4 так себе радость. Онлайн проверки у него опять же нет. А укладывать все в даун на полдня для офлайн fsck вы там сами как-нибудь, имхо. >> 1) например файлов с суммарным размером сильно больше sizeof(device). > С хардлинками/рефлинками свободное место прекрасно вычисляется. Хардлинки и рефлинки - абсолютно разная функциональность. Хардлинки в цать раз проще. Рефлинки... возможность референсить экстент более 1 раза. Это живет ближе к блочному уровню чем хардлинки, и как таковое фича аллокации. Более того, btrfs, XFS и bcachefs юзают вызовы "same extent" и "clone range" на которых все это основано в том виде как его btrfs впервые сделал - и там видите ли то что запрощено софтом - одно, а как это будет реально оформлено - best effort/implementation defined. И как при записи оно сплитуется для поддержки иллюзии независимости копий файла - тоже implementation defined. На самом деле очень эффективные штуки, можно флот VM допустим поднять из шаблона без фактического копирования - но cow прозрачно будет дописывать в сторонку расхождения и иллюзия независимости - будет. Это не совсем халявно и за это может воздаться. Но скорость операций и оверселл себе же места - это круто. > А если вы про сжатие, то их нет у меня, и не надо. А мне не надо - окаменелый антиквариат с кучей легасипроблем. И сказ о его перфомансе прохладный. Я видет что бывает с EXT4 при 50-100К файлов в дире. Я видел как XFS удаляет DVD-sized файло (torrent) _минуту_. Тоже знаете ли такой себе перфоманс в кейсах с которыми я встречался. >> 2) дофига файлов с 0 размером, суммарный размер 0 но место на девайсе - кончается?! > В ext4 есть такая проблема, хотя на практике я ее не встречал. Эта проблема есть в любой ФС которая позволит создать достаточно файлов. Секрет прост: метаданные тоже место жрут. Имя файла и проч тоже надо где-то хранить. Можно выюзать все место вообще - не заняв под "data" ни байта. Один читер так даже архиватор сделал под контест сжатия. Спросил организаторов - а можно эн файлов вместо 1? Можно! Он и стал сохранять данные исходного файла - в имена файлов. А размер файлов - ноль. Проблема только 1 - хотя формально степень сжатия бесконечная, места на ФС с этой активности почему-то не добавится. С тех пор оргагнизаторы контестов аккуратнее относятся к правилам :) > В отличие от. А в xfs и того нет. Да неужели? Он хранит имена файлов и проч в астрале? Не аллоцируя под это место? В этом месте вы спалили непонимание азов работы ФС. Вам рано пытаться блистать экспертизой с таким уровнем знаний. > Клал я на мордокнигу, меня волнует, что и как работает лично у меня. Как ни странно я тоже. Но такая толпа выпущенная на поляну и вытоптавшая ее - избавляет меня от кучи странных вещей. > с Linux данные похерил именно btrfs, причем на ровном месте и > безо всякой экзотики вроде raid и выключений питания. И включенные чексуммы не спасли. И конечно как обычно - деталей не будет? А так - в свое время господа типа вас рассказывали что от скорости 40 км/ч можно сойти с ума, куры перетсанут нестись, а у коров испортится молоко. Но почему-то молоко в магазине - есть, и btrfs у меня никак не разваливается. Хотя уж столько лет обещают. У меня уж этого btrfs распихано - а все не разваливается. Правда я не игнорю ор в системные логи и мониторю корректность работы железа. >> Вообще-то как раз оно за счет чексумм - и чинит кривую копию > Ну да, ну да. Гладко было на бумаге... Да оно и на практике - работает. А ext4 у меня как-то скопытился в эмбедовке с 1 бэд сектора. попал, понимаешь, подлец - под libc6. И все, система тыква и я все бросаю и в темпе вальса лечу это разэмбедовывать. А там 1 гребаный бэд под libc6 все урыл наповал. У меня уже с пару сотен юнитов такого добра раскидано по глобусу, там некому эти ваши долбаные fsck клацать и нянчиться с юнитом. В этом смысле DUP был неким апгрейдом. >> Хи-хи, я рефлинкну 3-терабайтный образ винча за несколько секунд. > Ну и молодец. А мне все вот эти экзерсисы нафиг не нужны. А я не собираюсь ограничивать себя ходьбой пехом и ездой на конской хребтине. Поэтому мы друг друга не поймем. Я уже декомисовал у себя EXT4 а XFS на мой вкус - вообще WTF'а кусок, ибо потуги сделать эрзац cow - без полного набора дотоинств оного - бессмысленное и беспощадное шиткомбо, имхо. Не, я не собираюсь юзать никакие сратисы. И LVM/md/dm/etc - вы там сами как-нибудь. После управления btrfs мне эта этажерка уже как-то совсем не того. > Мне надо, чтобы в повседневной работе система не тупила и при > этом работала надежно. А это не про btrfs. Я уже смог оценить надежность когда бэд в EXT4 накрыл libc6 и на этот случай плана нет вообще совсем. А вот btrfs теперь - и в этом случае потрепыхается, и до того как оно помрет по такой причине - оно сперва изрядно поспамит логи, давая время на маневр.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (21), 11-Сен-25, 12:14
	> На моих btrfs тоже, но это не означает что я при желании не смогу сделать довольно странные ситуации на них всех. При желании можно и свинью заставить летать. Речь не о том, как заставить ФС встать колом, а о том, насколько вероятно, что она встанет в повседневной жизни. И в повседневной жизни я не создаю миллионы файлов в директории, и большинство файлов имеют ненулевой размер. Даже если бы проблемы с inode возникли, решаются они довольно просто и очевидно - удалением или перемещением файлов. А с btrfs и ее филосовским отношением к свободному месту проблема может возникнуть именно при повседневном использовании. > Рефлинки... возможность референсить экстент более 1 раза. Рефлинк - этот тот же хардлинк, но с автоматическим COW. А то, что вы описываете - это как работает COW в btrfs. > Он хранит имена файлов и проч в астрале? Не аллоцируя под это место? Сами сказали, сами посмеялись? Вопрос в том, как хранятся inode. В ext4 выделена фиксированная область для их хранения, отсюда и проблема с out of space. В xfs (без inode32) inode могут храниться по всему диску, поэтому если ты забьешь его весь inod'ами, то свободного места у тебя будет 0. Но еще раз повторюсь, чтобы на это нарваться, надо специально постараться. > И конечно как обычно - деталей не будет? Тут вы правы - не будет. Дело было несколько лет назад и, уж извините, лично для вас я тогда детали не сохранил. Просто снес к такой-то матери полуразваленную btrfs и заменил на xfs, а данные восстановил из копии.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 13:06
	> При желании можно и свинью заставить летать. Речь не о том, как > заставить ФС встать колом, а о том, насколько вероятно, что она > встанет в повседневной жизни. У меня в повседневной жизни дофига btrfs-а и он колом не встает. Меня устраивает. И даже немного сабжа есть. Колом он тоже на мое счастье не встает, пару багов я видал, но ничего реально фатального. Но своими замашками с фс утилсами требующими "скачайте ночнушку!!111" кент сделал мою жизнь неудобной, и с учетом дропа ФС утилсов в моем дистро (которому тоже неудобна такая полися апстрима) - я склонен считать эксперимент интересным, но в целом - скорее неудачным, а с учетом ситуации с ядром все что юзало сабжа - отмигрирует на btrfs постепенно, там ничего ценного или критичного, обычные сервисные виртуалки, их легко отреспинить. Видите, ALL не обязан жрать кактус ЛЮБОЙ ценой. И тут Кент как-то перегнул палку. Да, у него хорошая штука. Но это не делает его пупом земли, которому простят все и вся. Если он это не понимает - печально, но тогда зачем мне делать из этого свои проблемы? > И в повседневной жизни я не создаю миллионы файлов в директории, А я вот иногда могу от 50 до 300К забацать. С фига я должен ограничиваться хомячковыми сценариями при эксплуатации ФС я не знаю. Поэтому хорошую работу в моих сценариях я буду считать за фичу. > и большинство файлов имеют ненулевой размер. Пойнт в том что вычисления свободного места в ФС - в целом просто некая достаточно абстрактная цифра. Чем эта цифра в btrfs так уж хуже чем в других - я не придумал. Ну да, т.к. фич больше - больше причин чтобы эта абстрактная цифра разошлась с ожиданиями. Но я уже дал пару примеров как эти ожидания полностью обломать даже и на классике. Т.е. никаких качественных отличий нет, количественные - может быть, но эту историю начал точно не btrfs. > Даже если бы проблемы с inode возникли, решаются они довольно просто и > очевидно - удалением или перемещением файлов. Вау круто, а если файлы нужны, мне наверное в ООН тогда писать петицию? Де факто статическая аллокация инодов - это визитка АРХАИЧНЫХ дизайнов. Это дурное наследие, никто более не будет новые дизайны по тем лекалам лепить. > А с btrfs и ее филосовским отношением к свободному месту проблема может возникнуть > именно при повседневном использовании. По состоянию на здесь и сейчас, с более-менее современными дистрами и ядрами - это все бред сивой кобылы. Там на совсем пиковые случаи с неких пор сделали небольшой global reserve. В случае когда "everything failed" юзается место из него, так что даже откровенно провальная операция типа дописать для удаления файла - успешно завершится. А еще - они сделали авто-GC блочных групп, по типу того что кент с buckets делает. И проблемы с резким изменением data/metadata ratio тоже в целом ушли. Понятно что предвидеть ВСЕ в сложном продвинутом дизайне было нереально, и какие-то траблы лезли. Но ваши знания 2010 года уже не особо актуальны. Да и тогда оно лезло лишь в специфичных случаях в которые ФС вообще не надо загонять, если перфоманс минимально интересовал. Т.е. забивка ФС более чем на 85-90% это создание кучи проблем аллокатору, дикая фрагментация и проч. В случае XFS при этом, вроде, нет никакого плана действий, кстати, а? У ext4 и btrfs есть какой-никакой дефраг. >> Рефлинки... возможность референсить экстент более 1 раза. > Рефлинк - этот тот же хардлинк, но с автоматическим COW. Хардлинк по сути просто +1 имя у файла. Файл - inode, у которого есть 0 или более имен. Если имен 0 то по нормальной семантике файл unlinked и деллаоцируется (когда его все закрыли). O_TMPFILE может немного поспорить с этим но это мало чем отличается от случая с inode где все имена отвязали но файл все же еще не закрыли и в ФС он еще держится, невидимый. Рефлинк это довольно абстрактная штука. Он не существует как некая конкретная сущность и как это ФС делает - implementation defined. Все крутится вокруг 2 вызовов (ioctl): 1) "same extent" - хинт дедупликации, утверждиющий энной ФС что вот этот и этот экстенты - дубликаты и можно заменить вон того - референсом на первого. Получив такой запрос на вход ФС должна проверить что это и правда так - и заменить одну копию референсом на вторую копию. Заметьте - имена файлов тут никак не фигурируют, и это могут быть разные никак не связанные файлы, все что критично - чтобы это были 2 идентичные регионы. Тогда 1 из них может быть деаллоцирован и превращен в референс. Этот рефенерс внутреннее дело ФС и его нигде наружу никак не видно. 2) "clone range" - мы просим создать типа-копию региона файла с содержимым "как вот тут". Де факто ФС повесит +1 референс на экстент(ы) а если туда что-то потом запишут, обыграет сплит этого cow. Это добро работает в режиме "best effort", у ФС могут быть свои идеи что она (не)может выполнить и то что запрос будет выполнен 1 в 1 как его программа выставила ниоткуда не следует, программе не видно внутреннюю механику произвольной ФС с этим и-фейсом, ФС лучше знает что она (не)способна обеспечить и как это будет выглядеть. И получается забавно: запустив прогу дедупа у меня ... формальный размер суммы аллокаций файлов не меняется, а свободное место - растет. Потому что часть дубликатов заменили референсами. > А то, что вы описываете - это как работает COW в btrfs. Я описываю как работают 2 характерных ioctl, которые с btrfs'а потом содрали, видите ли, XFS (которого для этого каким-то чудом расперли на лимтированный и кривоватый cow) и bcachefs. И рефлинки в zfs вероятно тоже через них же сделаны. Потому что кто же будет кодить софт "спецом под 1 фс" когда 3 другие юзают вон тот ифейс. В сорцах ядра эти ioctl у всей троицы явно деланы копипастой с btrfs'а. И устаканился такой вот интерфейс вызовов. К хардлинкам это все никак не относится, ибо ничего с именами файлоов не делает и в общем случае - "same extent" может вообще принадлежать совсем разным файлам. Которые никогда не имели ничего общего, но потом заимели, дедуп прога нашла это - и вывесила запрос замены 1 из копий _экстента_ +1 референсом. Заметьте, это не про _файлы_ или _имена_. Это довольно принципиальное отличие, реализация этих и-фейсов подразумевает некую форму CoW ибо иначе - а как при записи разбивать то клона, чтобы поддержать абстракцию независимости файлов? >> Он хранит имена файлов и проч в астрале? Не аллоцируя под это место? > Сами сказали, сами посмеялись? Вопрос в том, как хранятся inode. Вы не понимаете. На XFS можно создать дофига файлов 0 размера - выжрав все место одними только метаданными. Суммарно размер файлов будет - ноль. Да, это несколько экстремальный случай, для иллюстрации на тему того что цифирь свободного места - еще ничего не гарантирует. Видите, суммарно файлы 0 байтов а места - почему-то нет. Все ушло на метаданные. > диску, поэтому если ты забьешь его весь inod'ами, то свободного места > у тебя будет 0. И вот чего стоит цифря свободного места? Если она варьируется в широких пределах в зависимости от наполнения ФС и при no space left все равно sum(file sizes) != sizeof(dev size). Так что в лучшем случае это какой-то очень приблизительный ballpark даже в ext4 и xfs. В btrfs оно еще более приблизительное. И чего? Да, с RAID может стать еще чуть хитрее. Но если кто полез в продвинутости, ему придется понять азы работы продвинутого дизайна, чтобы избегать глупых обломов. А вы можете юзать хоть FAT16 если вам так хочется. > Но еще раз повторюсь, чтобы на это нарваться, надо специально постараться. Предсатвяляете, btrfs для меня тоже в целом - просто работает. Под сказки всяких сказочников. Может, "дело мастера боится" потому что я умею решать свои проблемы - и знаю девов этой штуки, так что "в случае чего" я ессно разберусь. Но пока этот скилл ни разу не пригодился, а страшилки с опеннета - приелись. Скажем прямо. > снес к такой-то матери полуразваленную btrfs и заменил на xfs, а > данные восстановил из копии. Какая типичная для опеннета история. С учетом вышеописанного вы уж простите мне мой здоровый скепсис, и ремарку что я все же буду ездить на поездах. И буду за поезда. С полным пофигом на ваши увещевания что куры перестанут нестись. Потому что я уже цать лет езжу на поездах а куры никуда не делись.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (21), 12-Сен-25, 04:54
	> По состоянию на здесь и сейчас, с более-менее современными дистрами и ядрами - это все бред сивой кобылы. Там на совсем пиковые случаи с неких пор сделали небольшой global reserve. В случае когда "everything failed" юзается место из него, так что даже откровенно провальная операция типа дописать для удаления файла - успешно завершится. Ну конечно бред. Наверно, мне приснилось просто, что ФС загнулась. И не в 2010, а года 3 или 4 назад. Началось как out of space с невозможностью удаления файлов, а потом вдруг обнаружилось, что половины файлов тупо нет. И места нет. А в остальном всё прекрасно, да. > И вот чего стоит цифря свободного места? Если она варьируется в широких пределах в зависимости от наполнения ФС и при no space left все равно sum(file sizes) != sizeof(dev size). А кто сказал, что сумма размеров файлов должна быть равна размеру раздела? Метаданные и журнал тоже где-то хранить надо. Вот тут эта самая цифра свободного места и обретает смысл, т.к. показывает, сколько можно записать. И это реально полезная инфа, т.к. позволяет заранее проверить, влезет ли то, что ты собираешься записать. Понятно, что в итоге может таки не влезть (например, если другой процесс тоже решил что-то записать, и вместе они не влезли), но в большинстве случаев это работает.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 16:33
	> Ну конечно бред. Наверно, мне приснилось просто, что ФС загнулась. Ну как бы без конкретики - мы говорим ни о чем. Конец истории. Вон у maximnik0 - есть сообщения, там тупых вопросов не возникает. Но у него проблема разрулилась. Однако я думаю что _реальная_ проблема - ему какая-то зараза таки втихушку память немного подбивает, или есть какая-то паскудненькая нестабильность. Потому что сами по себе деревья засираться все же не должны. > of space с невозможностью удаления файлов, а потом вдруг обнаружилось, что > половины файлов тупо нет. И места нет. А в остальном всё прекрасно, да. Это вообще странный сценарий. Ну и т.к. оно cow - на самом деле это лабиринт отражений. Если файлы реально нужны, можно btrfs restore'ом потыкаться в разные точки входа в CoW иерархии, отмотав по времени даже. Сколько-то generations назад все могло быть ОК, и если gc это еще не подгреб оно на отличненько прочтется. А вот например с EXT4 если что-то где-то как-то не того - упс. Это сразу и наповал фатально - файлуха переписывает файло in place и если мне даже и не ннавится что с ним случилось, старый вид данных я уже никогда и никак не выну. Он - сразу перезаписан, физически. И там уже нечего ловить с точки зрения дата рекавери, это продолбано навсегда, без возможностей маневра. Я себе так разок бэкап почты восстановил, заметив что он староват, а более новый вид почты - ну, его нет. И восстановить - ых, ых, ых, в общем почта за пару недель продолбалась нахрен. Кому сильно надо было - перепослали, конечно, но неудобно было. С btrfs я б даже и без снапшота бы - вынул что надо. А с снапшотом - еще и как белый человек. > А кто сказал, что сумма размеров файлов должна быть равна размеру раздела? > Метаданные и журнал тоже где-то хранить надо. В самом примитивном случае - нечто близкое к этому. Но как вы и заметили даже в примитвных дизайнах уже бывают отклонения. > Вот тут эта самая цифра свободного места и обретает смысл, т.к. показывает, > сколько можно записать. Но это не так. Как я уже показал - даже на EXT4 или XFS то что можно будет записать, по формальному размеру аллокаций будет варьироваться от 0 (все файлы 0 размера, все место выжрано на метаданные) до сильно более чем суммарная емкость девайса. За счет "оверкоммита" ака "holes" и проч - которые маркируются экстентами в метаданных, а не аллоцируются рельно. Кстати возможно великий эксперт пох (или нах?) именно поэтому и чесал репу как 6 гиг стали 10? Ну вот так и стали - при копировании на новый девайс holes ессно честно заполнились нолями и аллоцировались. Как одна из версий. > И это реально полезная инфа, т.к. позволяет заранее проверить, влезет ли то, > что ты собираешься записать. Но это знание в лучшем случае приблизительное, плюс-минус лапоть. Да, в btrfs лапоть бывает побольше. Но если не жестить - в целом норм. > что-то записать, и вместе они не влезли), но в большинстве случаев > это работает. И тем не менее я не вижу каких-то сильно принципиальных отличий. Может если совсем впритык на последних байтах играть - это и будет подбешивать больше, но на послдедних байтах вообще лучше не играть. Ибо аллокатору будет капец и перфоманс фс уйдет в полный хлам. Даже с EXT4. Де факто я одному хостеру так EXT4 убил что они блин меня двигали на другой хост чтоб это за мной разрулить, перекатав хост нахрен. Было стыдно, конечно, но - бывает.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (123), 12-Сен-25, 21:24
	> Это вообще странный сценарий. Ну и т.к. оно cow - на самом деле это лабиринт отражений. Если файлы реально нужны, можно btrfs restore'ом потыкаться в разные точки входа в CoW иерархии, отмотав по времени даже. Сколько-то generations назад все могло быть ОК, и если gc это еще не подгреб оно на отличненько прочтется. Учитывая, что место там на самом деле кончилось, всё что можно было gc уже собрал. Но суть даже не в этом. Если ФС можно положить таким тривиальным способом, даже если мне как-то уникально не повезло, то нафига козе баян? Зачем мне ковыряться в кишках ФС, когда я могу просто использовать другую ФС и не иметь этой проблемы в принципе? Тем более, что в моём случае речь шла о бекапе, который восстановить было относительно легко. Да, в xfs для моего кейса не хватает чексумм по данным. Но ничего, за пару часов набросал скриптец, который всё считает и проверяет, и хранит чексуммы в xattrs. Так что вышло плюс-минус как с btrfs, только без проблем последней. > За счет "оверкоммита" ака "holes" и проч Не использую, но даже с ними не вижу проблем. Ну есть у тебя дырявый файл, но ведь свободное место указано с учетом дырок. И записать ты сможешь столько, сколько есть этого места. Вот если ты попробуешь аллоцировать дырку и места для этого не найдется, то ты получишь ENOSPC или SIGBUS на эту конкретную операцию.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 11-Сен-25, 16:32
	Уф. Я даже несколько вот стесняюсь спрашивать -  а _нормальные_ для отрасли задачи у вас ну вот вообще - бывали хоть когда-нибудь? Не "накласть под себя 1000000 файлов в одну папку" (Зачем? Почему? Для чего? Что, дисперсию по дереву с 90х годов делать разучились? И нужна именно абстракция "файлы", а не "объекты"?), не "fsck'ать" N-терабайт - а вот выкинуть из кластера сбойную ноду, загнать вместо неё точно такую же, но живую, поднять бэкап-синкануть стейт? Не делать 100500 снапшотов VM на локалхосте, а спровижнить этот диск на хотя бы три гипервизора в кластере? Ну вот обеспечить гарантированную производительность дисковой подсистемы для СУБД, хотя бы?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	86. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 15:12
	> Уф. Я даже несколько вот стесняюсь спрашивать -  а _нормальные_ для > отрасли задачи у вас ну вот вообще - бывали хоть когда-нибудь? Это типа средней температуры по больнице? Я кастомдевом занимаюсь, люблю зарубаться с странноватыми проблемами, требующими продвинутого R&D. Это кроме всего прочего гарантирует что конкурентов немного. И вы точно не 1 из них. > Не "накласть под себя 1000000 файлов в одну папку" (Зачем? Почему? Для чего? 1) Видел в самопальной системе видеорегистрации, долго и радостно пахала, сама по себе, без супервайзинга. За сколько то лет накопила десятки тысяч файлов в EXT4. 2) Примерно такие же серваки попадались с всяким околосамопалом, навалившим кучу файлов. Условный пхпшник понятия не имеет что вывалить 100500 файлов в 1 диру может выйти боком. И задумывается лишь когда оно реально вышло боком. Ну или не вышло, от фс зависи :) 3) Для себя я не так давно репаковал энный специфичный архив. Мне надо было там пропатчить пару вещей и пересобрать это. А там и окажись под 300К файлов! Конечно я это не на EXT4 ворочал, а на btrfs, вполне одупляемо все. Стуктуру этого всего придумывал не я, уж какой формат есть - такой и есть. Крестовый поход по исправлению мира я затевать ради разовой фигни не буду. > Что, дисперсию по дереву с 90х годов делать разучились? И > нужна именно абстракция "файлы", а не "объекты"?), Современная ФС и так нечто типа базы key-value. Зачем МНЕ заниматься косплеем дерева, когда ФС сама сделает? Не тратя на это МОЕ время. А вы можете и заниматься кодингом половины логики дерева сами. Но в свое время. И конечно за этот изврат никто не заплатит дополнительно. Чисто техническая рутина не имеющая никакой ценности сама по себе. > не "fsck'ать" N-терабайт - а вот выкинуть из кластера сбойную ноду, > загнать вместо неё точно такую же, но живую, поднять бэкап-синкануть стейт? Баззворды. Не возбуждающие меня - протухли лет на цать. Мне не требуются кластеры, хотя ряд из моих идей вполне себе fault tolerant и scalable, чуть иначе. Я немного учусь у лучших из мегакорпов. Just because I can. Однако, на лично моем десктопе, лаптопе и проч - я тоже не собираюсь быть сапожником без сапог. Мои технологии должны работать хотя-бы для меня. Без этого мне все это просто не надо. Представляете? Это разные modus of operandi. Вы работаете на дяду. Я - на себя. > Не делать 100500 снапшотов VM на локалхосте, а спровижнить этот диск на хотя бы три > гипервизора в кластере? Ну вот обеспечить гарантированную производительность дисковой > подсистемы для СУБД, хотя бы? Если мне станет нужно - я смогу в линухе все что захочу. Но я берусь за задачи которые мне интересны и развивают меня в интересных мне направлениях. А вам нужен, пардон, IT-ассенизатор. Разгрести непотребства арзитектуры и менеджмента (я вижу это уже из постановки задачи). Ппри чем тут я? Подобного счастья с дино от айти я накушался досыта. И за добавкой не приду! Хочу заниматься более интересными задачами чем разгребание чужих архитектурных факапов (ваша постановка задачи называется на самом деле так). И заучивать ритуалы камлания на богов - не ко мне. Я сам уже на пантеон хаживать научился, линух для меня прекрасен тем что это - набор компонентов и технологий. Который подлежит декомпозиции и персборке в комбо которое я посчитаю уместным. Мне надо вот это, а не... А попытки даунплея проблемы и сказа что оно не особо то и надо - из разряда баек извозчиков что от скорости 40 км/ч можно сойти с ума.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от User (??), 12-Сен-25, 15:48
	Резюмирую: "Нет, я ПРОФЕССИОНАЛЬНО занимаюсь самоудовлетворением на локалхосте, но если захочу - то сделаю ВСЕ - но я не хочу, а так-то да-да, все могу и умею". Не то, чтобы этот ответ меня хоть как-то удивил или бы вызвал дополнительные вопросы...
	Ответить | Правка | Наверх | Cообщить модератору

	94. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (94), 12-Сен-25, 16:43
	> Не то, чтобы этот ответ меня хоть как-то удивил или бы вызвал > дополнительные вопросы... В какой-то момент времени я просто заметил что все кого я считаю крутейшими из профессионалов, те на кого я хотел бы быть похож - выходцы из именно любителей. Они делали что любили, и любили что делали. И постепенно стали лучшими в этом. Мне понравилось как это работает - и я захотел так же. И в целом вроде прокатило. А разгредать блевотину за недо-архитектами которым надо гараааантии, бжд, бандвиза бааазе (даже не знаю как еще понятнее написать "мы про#$%лись в архитектуре") - для этого есть например вы.
	Ответить | Правка | Наверх | Cообщить модератору

	98. Скрыто модератором	+/–
	Сообщение от User (??), 12-Сен-25, 17:44
	Был пьяницей Хайям? И я люблю вино! Был вором Франсуа? И я залез в окно! Взгляните на меня - я создан из достоинств! А то, что не поэт? Ну... Просто не дано.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 17:59
	> В какой-то момент времени я просто заметил что все кого я считаю крутейшими из профессионалов, те на кого я хотел бы быть похож - выходцы из именно любителей. Не удивительно. > Они делали что любили, и любили что делали. И постепенно стали лучшими в этом. Мне понравилось как это работает - и я захотел так же. И в целом вроде прокатило. Сам себя не похвалишь, никто не похвалит. А потом эти любители которые "стали лучшими" говорят "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management." Так что можно наблюдать как кадавр ломается под своим же весом. Зато без "ненужной архитектуры от академиков".
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	108. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 19:37
	> Не удивительно. В качестве яркого примера - собссно линух. "Wouldn't be as big and professional as hurd". И прочие Таненбаумы пшикающие на студня. И где теперь студень, а где таненбаумы и прочие hurd? Как-то я юзаю - вовсе не их, а продукт от студня. Который, так то, прикололся - и всем дал мастеркласс. Я знаю и несколько более специфичных примеров, например в электронике. Самые крутейшие кадры которых я знаю - это не мясники которые "деньги зарабатывают" а те кто сделал свое хобби заодно и способом заработка. Себе по кайфу. Мне завидно стало - и я тоже так хочу :) > Сам себя не похвалишь, никто не похвалит. Выше я похвалил - личностей которые точно не я. Однако я хочу работать в том же режиме. Потому что это круто и эффективно. И намного мощнее унылых мясников "просто зарабатывающих деньги". > "You'd think that all the basics would have been fixed long ago, > but they're not. We're still dealing with basic issues such as > memory management." И что в этом такого? Чудес в софтострое не бывает. А дурацкие проблемы есть у всех. Всегда. Потому что люди не боги и все и вся предусмотреть не могут. Тем более что требования меняются по ходу пьесы и то что было отлично вчера - сегодня уже фи! Как пример, раньше IO относительно проца было медленное и оверхед не сильно парил. А тут вдруг сверхскоростные SSD подвалили, их бандвиз существенный % CPU, iops немеряно, и тут вдруг оверхед на всех уровнях заиграл новыми красками. И начались ударные рефакторы базовых апей. Потому что жевать гигазы в секунду по страничке 4 кил за присест это очень уж не очень получается. И да, это и mem management касается. Folios как раз рядом. > Так что можно наблюдать как кадавр ломается под своим же весом. > Зато без "ненужной архитектуры от академиков". Ну так академики - даже вообще взлететь не смогли и поэтому страшно далеки от такой проблематики. Они вооон там, за взлетной полосой догорают. Хотя это уже так, дымящиеяс угольки от их проектов. Делом доказавшие что летать это вообще - не способно. Но вы можете доверить тушку им и юзать их продукты, конечно. Если это для вас офигенно работает. А я лучше линух поюзаю. Потому что он хорошо работает - для меня. Лучше чем остальное.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от maximnik0 (?), 11-Сен-25, 13:08
	>Вообще-то как раз оно за счет чексумм - и чинит кривую копию, если есть откуда А если обе копии методанных повреждены или некорректные то получаем удовольствие - при этом как я убедился опять нету специалистов по этой ФС ,гонят фигню типа жёсткий на помойку. Хорошо я теперь хоть понимаю как эта ФС работает и не паникую, понимаю что данные я вытащу- но опять утилиты не спасают,не могут даже зафиксировать ошибку :-( Хорошо хоть теперь не падают на ровном месте https://www.linux.org.ru/forum/admin/18068502 (Проблему решил )
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	74. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (73), 11-Сен-25, 20:29
	Копий должно быть 3+.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от maximnik0 (?), 11-Сен-25, 21:46
	> Копий должно быть 3+. А толку то ? Если методанные описывающие дерево устаревшие- можно и 4 копии неверные сделать. Да, есть в 3х летних fixed: что такую как у меня ошибку поправили - синхрометки теперь проверяют (состояние гонки - самые поганые тип   ошибок и при этом очень тяжело ловятся)
	Ответить | Правка | Наверх | Cообщить модератору

	95. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (94), 12-Сен-25, 16:51
	> Копий должно быть 3+. У него leaf дерева подзасраный. Правда я так и не понял - дубликата не было? Но воплей про облом чексум нет - так что дубликат в этом случае и правда мог бы и не помочь, если факап пролез между счетом чексум и реальной записью. Но это довольно узкий window of opportunity и мне вот тут интересно - а сбои чексум или read errors там были, или где? Поэтому и попросил посмотреть статистику. Интересно же - трухлявая железка, или что за барабашки такие. У меня из-за btrfs целая мини-коллекция всяких подлянок есть, от кривых шнурков SATA до проца иногда флипавшего биты, но вот как он в этот window of opportunity втиснулся без спама про csum error в логах мне все же интересно.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	82. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 12:34
	> А если обе копии методанных повреждены или некорректные то получаем удовольствие - Теоретически - это возможно. Но вероятность - _произведение_ довольно маленьких вероятностей, если мы допустим что сбои редкие (если частые, железка скоро умрет, ее надо заменить). Для тех кто _очень_ боится есть RAID1C3 и C4, усиленная версия - 3 и 4 копии. А логи лучше мониторить. Если лениво, у btrfs статистика есть, сколько read/write/csum error было, все дела, можно чекать порой. Для понимания здоровья системы. > при этом как я убедился опять нету специалистов по этой ФС > ,гонят фигню типа жёсткий на помойку. Для себя я сам буду таким специалистом, just in case. А если вдруг - я знаю где btrfs'ники отвисают, в сложном случае можно и помощь зала запросить. И да, а чем это от EXT4 так отличается? Я его знакомым эн раз выколупывал с полутрупных девайсов как датарек-любитель как раз потому что спецов по нему тоже или нет, или это стоит как самолет. А мне и половинка самолета по дружбе ок :-). > Хорошо я теперь хоть понимаю как эта ФС работает и не паникую, понимаю что данные я > вытащу- но опять утилиты не спасают,не могут даже зафиксировать ошибку :-( Мир не идеален. Но вообще из факапов мне так по крупному требовался разве что рестор супера разок, когда при power loss некая флеха 1 из суперов пролюбила, видимо FTL у нее - совсем гамно. Восстановил из другой копии - и дальше себе поехало. Хомы с фатом и жестче нарывались на таком - у них партишн слетал вообще. Обучалка не дергать флехи без размонтирования для хом :) А вот как вы corrupt tree получили, да еще без csum error? Проверяйте железо и стабильность системы. Что-то не так. Кто-то память бьет, вероятно. Или проц некорректно считает иногда. Хотя обычно при этом ор на csum error здорово лезет ДО таких приколов. Может вы его не заметили сие? Что у вас в /sys/fs/btrfs/<FS_UUID>/devinfo/1/error_stats на этой штуке вообше? Вместо 1 может быть и иное, если многодевайсный фс. Btrfs статистику факапов ведет, "со времени сотворения мира^W файлухи". В идеале там по нулям, разумеется. А если там иное ... ну вот зависит от. Там и read errors, и csums, ... - в общем некий джентльменский минимум для понимания что за нафиг. > Хорошо хоть теперь не падают на ровном месте > https://www.linux.org.ru/forum/admin/18068502 > (Проблему решил ) Вообще деревья сами по себе - не должны так рушиться. Это может быть индикатором каких-то стремных системных проблем, имхо. Посмотрите статистику ошибок вообще? У вас ничего не сыпется в железе? Что-то такое бывает при битфлипах, например. И еще. В некоторых случаях, на SSD, некоторые версии btrfs utils создавали метаданныые в single. Что совсем не круто. Если вдруг - очень рекомендую метаданные все же сделать DUP (если это однодевайсовое, иначе - RAID1). В более поздних btrfs utils это решение отыграли взад и теперь оно так и по дефолту. Но лучше проверить явно.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	84. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от maximnik0 (?), 12-Сен-25, 13:34
	> А вот как вы corrupt tree получили, да еще без csum error? > Проверяйте железо и стабильность системы. И память и диск проверял- нет проблем.А вот кривой ACPI есть- теперь  мучайся с S0iх .Теперь если выбрать интеграшку карту - при засыпание в ОЗУ ноутбук не проснется ,а в acpi куча ошибок, а производитель забил болт :-( > и read errors, и csums, ... - в общем некий джентльменский > минимум дл > Вообще деревья сами по себе - не должны так рушиться. Это может Согласен,но после удаления злополучного каталога: нет новых ошибок. А с флэш диском подумаю чтобы DUP сделать - на нем у меня  редко меняющихся файлы ,чтобы ресурс сэкономить.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 15:37
	> И память и диск проверял- нет проблем. Это довольно эфемерно. И тесты RAM - далеко не worst case, локализовано погреть энный чип максимально активной долбежкой туда - тесты обычно не допирают. Да и ремап адресов и проч - специально это сделать может быть не совсем просто, rowhammer'ы подтвердят. А вот например накопленая статистика в /sys/fs/btrfs/... за все время жизни файлухи уже более индикативна что там и где с фс бывало. Даже если логи и не мониторили, дает некие идеи. > А вот кривой ACPI есть- теперь мучайся с S0iх Вот этого добра бывает. Я даже комп который так с виндой виснет видел. Видимо на десктопах это вообще не особо тестируют. > Теперь если выбрать интеграшку карту - при засыпание в ОЗУ ноутбук не проснется, > а в acpi куча ошибок, а производитель забил болт :-( Интересно, а оверрайд ACPI в линухе на ЭТО действует? Линух же может и заоверлоадить часть ACPI таблиц, если очень надо. Правда, даже взвис по идее рушить ФС все же не должен сам по себе. > Согласен,но после удаления злополучного каталога: нет новых ошибок. А с флэш диском > подумаю чтобы DUP сделать - на нем у меня  редко меняющихся файлы ,чтобы ресурс сэкономить. Метаданные не настолько уж и много пишутся. Особенно если файло редко меняемое. Для себя я просто помониторил wearout indicator VS типовое использование, пришел к выводу что моему скелету, так то, будет похрен и перестал париться :) Записи метаданных если надо - можно урезать/оптимизнуть опциями монтирования типа ... commit=150  ... - в случае краха сие отбросит до 150 секунд того что было. Ну или сколько кому нравится, более 300 секунд - варнинг дает, да и продолбать более 5 минут жизни системы наверное не совсем айс. Оно ж просто забивает на недописаный хвост - и все "рекавери" этой штуки по сути. Cow позволяет рекавери дешево и сердито, ФС просто оказывается в немного более старом виде.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от maximnik0 (?), 12-Сен-25, 19:53
	>А вот например накопленая статистика в /sys/fs/btrfs/... за все время жизни файлухи уже более Это где write _errs .... read_errs ? Везде все 0 .Все доступные разделы.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от maximnik0 (?), 12-Сен-25, 20:05
	> подумаю чтобы DUP сделать - на нем у меня  редко меняющихся файлы ,чтобы ресурс сэкономить. Пишут что с версии 5.15+ всё,DUP. И если верить btrfs fi df /мой раздел у меня system и metadata DUP.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	26. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (26), 11-Сен-25, 03:55
	> В чём заключается "nextgen"? Чексумы, сжатие, снапшоты, многодевайсность, CoW с семантикой почти как полный журнал - без потерь скорости от двукратной записи данных. Можно расширить - даже RAID - просто воткнув +1 девайс и сказав "btrfs device add" после чего вот вам +N места. Даже если это RAID был. А если столько места в эн-дисковом пуле стало не надо, можно энный девайс и device remove - и вынуть его из ФС. Можно профайл RAID сменить. Проверить чексумы по всем занятым регионам. И проч. И это все - нонстоп. На лету. Без прерывания сервиса и неюзабельности компа/сервера/whatever на дофига времни как у вон тех. Это менеджмент девайсов, места и ФС как это должно было быть с самого начала. Когда оно просто работает, и просто - человекам. В управлении и обслуживании (которое в идеале почти отсутвует в нормальном курсе событий).
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	34. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–1 +/–
	Сообщение от Аноним (34), 11-Сен-25, 07:07
	>[оверквотинг удален] > это RAID был. А если столько места в эн-дисковом пуле стало > не надо, можно энный девайс и device remove - и вынуть > его из ФС. > Можно профайл RAID сменить. Проверить чексумы по всем занятым регионам. И проч. > И это все - нонстоп. На лету. Без прерывания сервиса и > неюзабельности компа/сервера/whatever на дофига времни как у вон тех. > Это менеджмент девайсов, места и ФС как это должно было быть с > самого начала. Когда оно просто работает, и просто - человекам. В > управлении и обслуживании (которое в идеале почти отсутвует в нормальном курсе > событий). Есть один момент занятный. В RHEL Xfs есть, а Btrfs нет. Интересный момент, думаю.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 07:48
	> Есть один момент занятный. > В RHEL Xfs есть, а Btrfs нет. Интересный момент, думаю. Есть еще 1 момент, не менее занятный: в RHBM по сути не осталось известных блочнофайлушников. Даже экс-майнтайнер XFS, Деррик Вонг оттуда сдриснул - и отвисает почему-то с btrfs'никами в основном. Видимо не прикольное это дело - пытаться из пенсионера делать чемпиона-олимпийца. А код от дидов - это весьма такой себе ассет. Вот майнтайнер по совокупности и задолбался с потока багов который ему выгружал Syzbot. На память об этом XFS v4 задепрекачен, без нормального пути миграции на v5, в общем как обычно - проблемы индейцев шерифа не волнуют. Отличный выбор для эксплуатации... если есть товарный состав бабок на RHBMовский саппорт чтобы они сами свой кал и разгребали. А если не сами - вот это уже печальненько будет такое. Да, и этот их Джожеф Басик теперь тоже - не их. А очень даже фэйсбучный и довольно годно btrfs пилит. А в RHBM - шушера нонеймовская, с отчетиками что вот вот уже почти что-то там стабильное. И так уже лет i++ примерно. Для всего.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (34), 11-Сен-25, 12:24
	>[оверквотинг удален] > Вот майнтайнер по совокупности и задолбался с потока багов который ему выгружал > Syzbot. На память об этом XFS v4 задепрекачен, без нормального пути > миграции на v5, в общем как обычно - проблемы индейцев шерифа > не волнуют. Отличный выбор для эксплуатации... если есть товарный состав бабок > на RHBMовский саппорт чтобы они сами свой кал и разгребали. А > если не сами - вот это уже печальненько будет такое. > Да, и этот их Джожеф Басик теперь тоже - не их. А > очень даже фэйсбучный и довольно годно btrfs пилит. А в RHBM > - шушера нонеймовская, с отчетиками что вот вот уже почти что-то > там стабильное. И так уже лет i++ примерно. Для всего. А если в RHEL так всё плохо, то что по-вашему тогда эталон, из интерпрайзных, на который можно равняться? И почему?
	Ответить | Правка | Наверх | Cообщить модератору

	57. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–1 +/–
	Сообщение от Аноним (57), 11-Сен-25, 13:36
	> А если в RHEL так всё плохо, то что по-вашему тогда эталон, > из интерпрайзных, на который можно равняться? И почему? Равняться на него имеет смысл только узкой группе фирм входящих в фортуну 500 - способных подогнать товарный состав денег за саппорт. IBM меньше чем это - не интересует, извините. Если вы не оно - эталон не про вас. Потому что никаких бенефитов с всего этого вы не получите. А так у RH в целом - нормальные ядерщики все же есть. Которые в случае крутого факапа все же могут быстро и эффективно с проблемой справиться. А какая-нибудь убунта - с парой тыщ комитов в ядро за всю свою историю - сможет что? Сопли пожевать? Какие-то небольшие адаптации и свою специфику они смогут зарулить. Но резко решить крутую проблему с ядром у топового кастомера? Вот это уже не факт. Но это в целом. А с ФС у RH последние несколько лет - позор какой-то. Включая всю эту историю с XFS, сратисом и чем там еще - и потерей всех видных блочно файлушных имен из мира Linux в результате этого треша и позора. Да и вот в соседней новости тут был эталон баззвордов и хайпа от руководителя десктопного направления. Когда он там программу переписал с немодных GTK2 и GL на GTK4 и вулкан используя AI. А попутно жесточайше спалив свою квалификацию - AI его лоханул, считая все на CPU :D :D а этот тупарь даже не заметил, запилил статью, и в сумме - ну, окей, его квалификация теперь как на ладони. Хайп штука такая, обоюдоострая :) Конкретно в вопросах ФС я б вообще равняться на RH не стал. Ну не, нагруженные бд вроде на XFS неплохо живут. Но если вы не про это - не понимаю зачем с этим связыватсья. И менеджить место чем-то типа сратиса... господи, я боюсь даже представить себе что будет если пока оно там что-то менеджит что-то пойдет не так. Тут кастомеры RH познают зачем они товарный состав денег завезли, манагемент накрячит всех этих индусиков и они будут хоть руками кастомерские байты перебирать. А вот если вы товарняк денеu КРИЬ не завозили - я понятия что вы делать будете. Как говорится - good luck and godspeed. Можете также попытаться менеджить всю эту этажерку наслоений мануально и не спятить, конечно. Но имхо это такое себе. И это причина по котрой современные дизайны типа btrfs и сабжа делают это иначе.
	Ответить | Правка | Наверх | Cообщить модератору

8. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
Сообщение от Аноним (8), 10-Сен-25, 23:26
Логично, OpenSUSE - один из ключевых разработчиков BTRFS.
Ответить | Правка | Наверх | Cообщить модератору

	16. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (16), 11-Сен-25, 02:06
	https://get.opensuse.org/ru/desktop/
	Ответить | Правка | Наверх | Cообщить модератору

	51. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от KHD13 (ok), 11-Сен-25, 12:12
	Эти ушлёпки когда включили btrfs по умолчанию, у меня через дней 10 начала загружаться консоль и вопить, что мало места! А это самое место, было занято снапшотами btrfs, по умолчанию сусевцы сделали их 50 штук! Вернулся на ext4
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

10. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+3 +/–
Сообщение от Аноним (10), 11-Сен-25, 00:35
ФС создают умные люди со своим мнением, а такие самому лучшему управленцу в мире ненужны. К финишной лабе хорошо подходят безынициативные снежинки с двумя извилинами как у ИИ.
Ответить | Правка | Наверх | Cообщить модератору

	20. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	–2 +/–
	Сообщение от Аноним (-), 11-Сен-25, 03:08
	> ФС создают умные люди со своим мнением, Которые как правило не понимают простой вещи. Их ум и экспертиза - узконишевые, в своем топике. А во всех остальных они ... зачастую по нулям! 1) Рейзер. Профакал фирму, продолбал сотрудников, убил жену и попал на пожизненное. Это, типа, успех менеджмента фирмы, проекта или хотя-бы своей жизни, чтоли? Серьезно? Кстати ФС писать для такого итога - совершенно не требуется. Можно пирожки печь с тем же успехом. 2) Шишкин. Рассказал всем какие они п...сы. Продолбал Reiser4. Не осилил Reiser5. И отвалил в туман, теперь это какой-то нонейм без своих проектов вообще. Известный тем что на всех д@рьма слил при отсутствии своих достижений в основном. > а такие самому лучшему управленцу в мире ненужны. К финишной лабе хорошо > подходят безынициативные снежинки с двумя извилинами как у ИИ.   В девелопе софта все в курсе что best is mortal enemy of good enough. ФС не исключение, как видите - те кто гонялись за идеалом слишком долго, заметили что если в матрице висеть слишком долго, вернуться из нее вообще потом не получится. Релиз не состоится никогда. И для всего остального мира - в таком виде нет никакой разницы с тем как если бы вас никогда не существовало в природе. Не очень крутое достижение для софтварных проектов.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+4 +/–
	Сообщение от Аноним (21), 11-Сен-25, 03:20
	> Шишкин. Рассказал всем какие они п...сы. И ведь, что характерно, оказался прав.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (40), 11-Сен-25, 08:35
	>> Шишкин. Рассказал всем какие они п...сы. > И ведь, что характерно, оказался прав. И ведь что характерно - не релизнул ни 1 продукта под своим именем в результате. А раз так - его заслуги - ну, их нет. Похамить и свалить в закат - не больно какая заслуга перед человечеством.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (21), 11-Сен-25, 11:53
	Так-то патчи с reiser4 он поддерживал и развивал. Как сейчас - не знаю, не слежу.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 12:20
	> Так-то патчи с reiser4 он поддерживал и развивал. Как сейчас - не > знаю, не слежу. Ну да, так то, с отставанием на дофига - что-то там пыжился изобразить. Но в ядре довольно большие рефакторы вокруг блочнофайлушного, из-за сверскоростного IO типа nvme и проч, там всерьез взялись за перфоманс и оверхед. Гроссмейстера на столько счастья как я понимаю просто не хватило. Это ж не супер-алго в ФС кодить а довольно рутинные вещи менять - тем более трекая девелоп ядра чтобы понимать что и как менять. Тем временам стало понятно что дизайн Reiser4 уже и современным чаяниям не очень соответствует, до фичесета уровня btrfs/zfs/$subt можно и вообще не дожить. А просто очередной EXT4-like никого не возбуждает уже. И вот по итогам в активе шишкина есть: Reiser4 - некий зомби, который толком никогда не жил. По сути проект слит. Reiser5 - vaporware вообще. Это не бог весть какой список достижений чтобы с ним лезть других учить чему-то.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+1 +/–
	Сообщение от Аноним (-), 11-Сен-25, 18:34
	Шишкин красиво свалил в закат, кинематографично, как герой вестернского кино на лошади. Не все умеют красиво и изысканно сваливать.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	109. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Имя (?), 12-Сен-25, 19:38
	Шишкин про технические проблемы ФС рассказал, а не хамил. Если содержательная критика решения воспримиается как хамство, это к психологу надо идти, травмы детские лечить :)
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	45. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 10:50
	При этом лез к этим 321ам, хотел сотрудничать. Неудобненько получилось)) Хотя судя по поведению, он и сам не особо лучше оказался.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	44. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (44), 11-Сен-25, 10:28
	А я вообще не понимаю как можно знать все или около того. ФС это реально сложная штука и есть люди которые в этом норм разбираются,думаю интеллект таких людей уж точно выше среднего. Может какой-нибудь пан Пох в силу возраста и знает много,но ведь его мало кто понимает.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	50. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 11-Сен-25, 12:12
	> пан Пох в силу возраста и знает много,но ведь его мало > кто понимает. Пан пох... 1) Сделал ставку не на ту лошадь. Его проприетарная юниксная кляча сломала ногу. А что делать в этом случае у него вообще плана не было. 2) Его экспертиза в Linux застряла в 2010 году. Он до сих пор не понял что Linux это не такой себе unix, а вполне себе самодостаточная штука. Которая будет создавать погоду. Забыв его ценное мнение спросить и посчитаться с какими там еще (полу)трупами BSD и соляр. Это они пусть с лидерами рынка - считаются. А суммарно этот сэр - сбитый летчик. И его участь в целом достаточно незавидна. А для понимания он мне пытался рассказывать за графический стек линя и кто там что - при том что я лично работал над решением своих проблем с дровами GPU с airlied и его тусовочкой. Но у него хватило наглости попытаться рассказать мне его небылицы несмотря даже на это. Зато я отлично откалибровал мой ламометр на такой запредельной наглости.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+2 +/–
	Сообщение от Аноним (63), 11-Сен-25, 17:28
	> при том что я лично работал над решением своих проблем с дровами GPU с airlied и его тусовочкой Зашкаливающее количество твоих комментариев говорит о том, что ты можешь работать только над комментариями. Хотя, учитывая, что ты на неудобные вопросы тупо повторяешь одну и ту же лабуду, на которые тебе уже приводили опровержения многие уважаемые Анонимы (а у меня все анонимы уважаемые, если наши мнения совпадают :) ), проблемы у тебя не сложные. Работал он, как же. Такой же тролль, как ЭксконтрибуторFreeBSD, или два виртуала.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В пакетах с ядром для openSUSE отключена поддержка BCacheFS"	+/–
	Сообщение от Аноним (-), 12-Сен-25, 12:51
	> Зашкаливающее количество твоих комментариев говорит о том, что ты можешь работать только > над комментариями. Да понимаете в чем дело? На#$%ывать самсебя - контрпродуктивное занятие! Зачем мне быть крутым "на бумаге" сидя в раздр@ст@ной системе? Чтобы что?! Вы еще не заметили что я не фанат режима "сапожник без сапог"? Первую пару я традиционно одеваю сам. Ну или не первую если скилл улучшился. > многие уважаемые Анонимы (а у меня все анонимы уважаемые, если наши > мнения совпадают :) ), проблемы у тебя не сложные. Спасибо, улыбнули. Тут прекрасно все, от потуг полить оппонента без аргументов до критериев уважения. > Работал он, как же. Такой же тролль, как ЭксконтрибуторFreeBSD, или два виртуала. Да вы мелко плаваете. Vожет я десяток анонимов косплею?! Или - берите выше - ВСЕХ?! :D. Но все же не понятно откуда я отгда узнал как правильные опенсорсные взаимодействия выглядят. Если вы хотите сказать что я такое придумать смог - блин, вы мне льстите, у меня не настолько крутая фантазия.
	Ответить | Правка | Наверх | Cообщить модератору

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

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