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

"В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachefs"	+/–
Сообщение от opennews (??), 07-Фев-24, 14:00
В файловой системе bcachefs, входящей в состав ядра Linux начиная с выпуска 6.7, при подготовке к релизу ядра 6.8 были обнаружены и исправлены две серьёзные проблемы (исправления войдут в состав выпуска 6.8-rc4). Первая проблема связана с некорректным функционированием блокировок при работе с директориями, из-за чего при удалении несуществующих подразделов (subvolume) первая попытка удаления могла завершиться ошибкой, а вторая - зависанием, из-за оставления неснятой блокировки... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60565
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–10 +/–
Сообщение от Аноним (1), 07-Фев-24, 14:00
Кент не вывозит походу :(
Ответить | Правка | Наверх | Cообщить модератору

	3. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+27 +/–
	Сообщение от Аноним (3), 07-Фев-24, 14:04
	Да все он вывозит. Здесь просто, наконец, его поделие начали тестировать нормально - отсюда и получается выявление новых багов. Собственно, вот вообще ничего неожиданного нет. Исправит и дальше будет пилить фичи.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Пряник (?), 08-Фев-24, 15:32
	Как этот код вообще приняли без проверки? Три месяца прошло!
	Ответить | Правка | Наверх | Cообщить модератору

	167. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 16:32
	> Как этот код вообще приняли без проверки? Три месяца прошло! Пришел бы да показал нам мастеркласс с проверкой 90K LoC лучше. Кстати после этого, если бы прокатило, ты бы смог легко устроиться каким-нибудь руководителем направления тестирования в почти любой мегакорп по твоему выбору, без собеседования. С годовой зарплатой которой хватит на джет, яхту и еше останется.
	Ответить | Правка | Наверх | Cообщить модератору

	4. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+11 +/–
	Сообщение от llolik (ok), 07-Фев-24, 14:14
	Да всё он вывозит. Проект начал выходить в свет. Соответственно, больше тестеров, больше конфигураций/железа/кривых рук/ит.д. Соответственно и неочевидные ошибки полезли. Нормальное начало обкатки "на людях" свежего кода.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	26. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:43
	> Да всё он вывозит. Проект начал выходить в свет. Соответственно, больше тестеров, > больше конфигураций/железа/кривых рук/ит.д. Соответственно и неочевидные ошибки полезли. > Нормальное начало обкатки "на людях" свежего кода. Ну дык. Ухитриться 2 раза стереть несуществующий subvol - при нормальной эксплуатации еще ухитриться надо. Но если все же протупил и это получилось - клин операции в недрах файлухи все ж будет достаточно досаден.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от dalco (ok), 07-Фев-24, 17:09
	Руками такое сделать сложно, но можно. А вот косячным скриптом...
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 18:13
	> Руками такое сделать сложно, но можно. А вот косячным скриптом... Ну вот скриптом делающим фигню, типа горбатого авто-манагера снапшотов, можно попробовать. Однако скрипт который вызывает "bcachefs sub del" без проверки их существования - довольно странная штука, я б сказал. Как минимум дергать такую операцию наобум - довольно неоптимально будет.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 07-Фев-24, 17:36
	Абсолютно нормально пытаться удалить по таймауту. Точно так же нормально игнорировать неудачу и пытаться удалять дальше. Ты просто слишком ограниченный, чтобы придумать применение, не твоё это.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	43. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от Аноним (-), 07-Фев-24, 18:11
	> Абсолютно нормально пытаться удалить по таймауту. Точно так же нормально игнорировать неудачу > и пытаться удалять дальше. Да никто не спорит что баг - просто в практических сценариях на него наткнуться вообще не очень просто, а с учетом экспериментального статуса файлухи - явно не самое плохое что в экспериментальных ФС бывает. Если это самое страшное что у кента было, он все правильно делает и уровень качества на момент комита внушает почтение. > Ты просто слишком ограниченный, чтобы придумать применение, не твоё это. А вот давайте обойдемся без культуры уровня дворовой гопоты? Такой себе уровень.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (41), 07-Фев-24, 18:02
	> Ухитриться 2 раза стереть несуществующий subvol Да хоть 200 раз, в чём проблема-то? Такие вещи обязаны быть идемпотентными. Или ты из тех, кто перед удалением файла проверяет его наличие?
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	6. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от User (??), 07-Фев-24, 14:30
	Да нет, все идет по плану - приходите через десять лет, но это не точно - может еще какая модная балалайка появиться.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	28. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (-), 07-Фев-24, 16:51
	> Да нет, все идет по плану - приходите через десять лет, но > это не точно - может еще какая модная балалайка появиться. А ваши предки, наверное, были из тех, рассказывавших что от скорости более 40 км/ч можно сойти с ума, а от паровозов куры перестанут доиться^W нестись и у коров пропадет молоко. ...время шло, а куры и коровы вроде на месте, и более-менее свое дело делают.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (40), 07-Фев-24, 18:01
	> от скорости более 40 км/ч можно сойти с ума, а от паровозов куры перестанут доиться^W нестись и у коров пропадет молоко. > ...время шло, а сумашедших, рассекающих на скоростях выше 40 км/ч так и не появилось починил.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 18:18
	>> ...время шло, а сумашедших, рассекающих на скоростях выше 40 км/ч так и не появилось > починил. Странно, а я в поезде мерял скорость по приколу GPS'ом. Намерял 120 км/ч. Наверное меня наели.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от User (??), 07-Фев-24, 21:55
	>> Да нет, все идет по плану - приходите через десять лет, но >> это не точно - может еще какая модная балалайка появиться. > А ваши предки, наверное, были из тех, рассказывавших что от скорости более > 40 км/ч можно сойти с ума, а от паровозов куры перестанут > доиться^W нестись и у коров пропадет молоко. > ...время шло, а куры и коровы вроде на месте, и более-менее свое > дело делают. Ну, судя по тому, что вы тут пишете - ваши предки на премию дарвина тоже не наработали. Хотя... как там в анекдоте? "Расстреляли меня, внучОк, расстреляли"(Ц)
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	69. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от Аноним (-), 07-Фев-24, 23:57
	> Ну, судя по тому, что вы тут пишете - ваши предки на > премию дарвина тоже не наработали. Очевидно. А с такими как вы - мы бы на деревьях гикали до сих пор. Потому что взять в руки камень - это для слабаков, а к палке примотать - вообще жульничество. > Хотя... как там в анекдоте? "Расстреляли меня, внучОк, расстреляли"(Ц) Для лично меня такие как вы - лишний элемент пейзажа, ошибка эволюции. Простите уж за честность.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от User (??), 08-Фев-24, 07:30
	Ваше мнение очень важно для нас (нет) - ждем экспертную экспертизу от экспертов форчун500 - что там из-под одеяла Кента доносится? Когда для продакшна (Ваши с котом виртуалки и перешитый dir-300 не предлагать) готово будет? Слепая Ванга прочитала в катренах нострадамуса, что не ранее следующей недели и не позднее 2034го года после выпадания в жидкой форме 2к34 осадков в четверг майкрософт перепишет последнюю строчку с c# на rust, аноним оторвется от комментов и за один день зафиксит последний баг, отрелизится LTS-ядро, которое войдет в состав красношапки-с-двузначным-номером, на которую перейдет фейс... а, не - они уже - мамазон, в следствие чего и наступит оффтопикокапец во всем мире?
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от 128557 (?), 08-Фев-24, 08:15
	Что Вы курите, уважаемый, чтобы такая каша в голове была?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от User (??), 08-Фев-24, 09:43
	> Что Вы курите, уважаемый, чтобы такая каша в голове была? Ну, в данный момент - комменты некоего анонимного энтерпрайз-админа из fortune500 на фрилансе, исправлятеля-багов-линукса-за-один-день, астролога-телепата и просто скромного эксперта по всем вопросам.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:01
	> Что Вы курите, уважаемый, чтобы такая каша в голове была? Да эт виндового потребителя штормит с того что у нас в линухе технологии видите ли круче :). Завидовать молча - он не умеет, а синдром утенка так и прет.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	18. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от Kuromi (ok), 07-Фев-24, 15:47
	Да не, обычная история. На примере ФФ - вливают новый код (особенно если изменение значительное), тестят. Вроде все норм, пушат в ночнушку - получают вал багов и падений. Фиксят их, далее уходит в бету и опять куча багов вылезает. Все таки не может разраб продумать все возможные случаи и комбинации условий. Все равно никто в здравом уме сейчас bcachefs не пользует для чего либо кроме тестов и "пощупать".
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	37. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 07-Фев-24, 17:43
	Я пользую для кэширования мееедленного харда на SSD. Больше ничего не тыкаю, естесно.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Kuromi (ok), 08-Фев-24, 17:12
	> Я пользую для кэширования мееедленного харда на SSD. Больше ничего не тыкаю, > естесно. Именно bcachefs или более ранний bcache?
	Ответить | Правка | Наверх | Cообщить модератору

	19. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от Шарп (ok), 07-Фев-24, 15:55
	Да всё он вывозит. Просто в сишке нет RAII, чтобы запилить блокировку, которая сама снимается при выходе из зоны видимости.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	29. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:55
	> Да всё он вывозит. Просто в сишке нет RAII, чтобы запилить блокировку, > которая сама снимается при выходе из зоны видимости. Совсем не факт что ты хотел в ФС именно вот это вот. ФС это такой весьма многопоточный "handler" и будет очень не круто если разные части ФС друг с другом столкнутся, делая конфликтующие операции. Это идет несколько дольше RAII, и являет собой "очень продвинутый арбитраж ресурсов". Там еще есть например фоновые воркеры и ядерные треды - которые работают параллельно/асинхронно/дефернуто - и еще перфоманс всего этого очень критичен, иначе на скоростном стораже встревает на именно блокировках, и - "system is thrashing". Т.е. она ничего не делает, туповейтит в блокировках большую часть времени. Что не есть гуд. Совсем без блокировок тоже нельзя - взаимо-конфликтующие параллельные операции столкнутся.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (41), 07-Фев-24, 20:16
	> Совсем без блокировок тоже нельзя - взаимо-конфликтующие параллельные операции столкнутся. Можно. Неблокирующие структуры данных и упорядочивание операций спасут от блокировок. Для баз данных работает, значит и для ФС будет работать.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 00:00
	>> Совсем без блокировок тоже нельзя - взаимо-конфликтующие параллельные операции столкнутся. > Можно. Неблокирующие структуры данных и упорядочивание операций спасут от блокировок. > Для баз данных работает, значит и для ФС будет работать. Простите, а как например GC параллельно с этим всем гонять - не наступая себе на хвост? В базе зачастую ответ - "никак" но cow-файлухе так не катит. Почему-то. Bcachefs таки слизал ряд идей БД и bcache - но вообще совсем без блокировок все же не получилось хотя автор явно в курсе тех идей. Если вы такие умные - покажите мастеркласс, м?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (47), 07-Фев-24, 18:27
	> RAII Ее и в ассемблере нет.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	106. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (106), 08-Фев-24, 11:30
	Как же вы достали. Во первых есть расширение на уровне компиляторов. Во вторых - никто не мешает организовать это на уровне макроса-структур и менеджера памяти. В третьих, 90% проблем ловится статическим анализом, а то что не ловится - проблема в логике от которой не защитит НИКАКОЙ яп.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	142. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:58
	> Как же вы достали. > Во первых есть расширение на уровне компиляторов. > Во вторых - никто не мешает организовать это на уровне макроса-структур и > менеджера памяти. В третьих в линухе даже и круче есть - там подобие деферов сделали, это даже более крутой и универсальный механизм. Только вот он не замена блокировок в том виде каком это ФС актуально. В ФС происходит несколько параллельных, независимых действ, в практически независимых сегментах кода (e.g. ядерном треде или wq) и надо чтобы они сообща - не наломали дров, наехав друг другу на хвост. > В третьих, 90% проблем ловится статическим анализом, а то что не ловится > - проблема в логике от которой не защитит НИКАКОЙ яп. Отладка сложного кода с нетривиальными параллельными взаимодействиями вообще не универсальный топик без серебряных пуль. Скажем какой-нибудь тред GC - по сути почти отдельная программа в каком-то роде. Работает независимо от всего остального, логически декорелирован - чтобы кодер не спятил случайно от уровня сложности действа - но он не должен столкнуться при своей работе с иной активностью, потенциально происходящей в его регионах интереса по другим поводам. И тут оказывается что совсем без блокировок - ну вот упс. И если кто думает что файлушники их любят или делают это по приколу - да вот фиг.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (-), 07-Фев-24, 16:27
	> Кент не вывозит походу :( Что он там не вывозит? Локап в файлухе - ну, не айс. Но даже не разрушение данных - при том что ФС без году неделя и ее только 1 версию ядра как активно гоняют все кому не лень. Ну и вот - кто-то заметил пару багов. А Кент вывез и починил - по мере обнаружения проблем. И если так рассуждать - ничего что в EXT4 до сих пор баги чинят? :)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	108. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (108), 08-Фев-24, 11:32
	Дак а что ты молчал то, когда ее в ядро принимали? Почему не остановил, если все изначально знал?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
Сообщение от inklesspen (ok), 07-Фев-24, 14:01
С самого начала было понятно, что bcachefs пока еще не готов и находится в экспериментальном виде. Достаточно просто взглянуть на количество и качество иссушек на GitHub. Однако текущее состояние ФС не мешает проводить различные тестирования производительности, подыскивать применение на будущее. Автор например на реддите вроде писал, что ФС имеет отличную масштабируемость, даже если скорость работы в 1 поток не велика.
Ответить | Правка | Наверх | Cообщить модератору

	27. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:47
	> Однако текущее состояние ФС не мешает проводить различные тестирования производительности, > подыскивать применение на будущее. Ну кстати при принятии в кернел пришлось пойти на ряд компромиссов - и реально оно звезд с неба не хватает. Фороникс побенчил, в нескольких кейсах прикольно всех натянуло - но в нескольких других с таким же треском и проср@ло. До тюнинга и оптимизаций дело еще не дошло. Сперва - обезглюк. > Автор например на реддите вроде писал, что ФС имеет отличную масштабируемость, даже > если скорость работы в 1 поток не велика. В целом он учел некоторые узкие моменты того же btrfs. У того видите ли при активной многопоточной записи случается lock contention на extent tree. И это на пачке быстрых сторажей может уже и нагнуть производительность так то. По поводу чего есть такая штука как Extent Tree V2 (это экспериментальная фича btrfs, ее нельзя использовать в продакшне!).
	Ответить | Правка | Наверх | Cообщить модератору

	63. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от PnD (??), 07-Фев-24, 22:00
	> это экспериментальная фича btrfs, ее нельзя использовать в продакшне BTRFS в проде? Я как-то здесь писа́л что была в эксплуатации 1 штука. По той причине что идеально ложилась на задачу (снапшот снапшота снапшота, и все в RW). Так вот, уже́ нет. Сложилась в немонтируемое состояние просто на очередном рефлинке. Единственный позитив что предусмотрен механизм экспорта данных. И он таки отработал (x5 к месту на СХД в данном случае). Вытащил и перепаковал в zfs. С реальным геморроем на переписывание операций над снапшотами (и потерей в моменте консистентности). Но даже так, в проде едут 20+ штук zfs. Это всё тоже сильно специфические применения, с известным (не факт что досконально) набором нюансов. Но едут, и совсем уж на ровном месте не складываются. * Просто там где такая специфика, нет идей устраивать гонки на перезаписи файлов и т.п., на чём отдельные эксплуатанты фрюхи нажигаются. (Спасибо им за это, серьёзно.)
	Ответить | Правка | Наверх | Cообщить модератору

	71. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (-), 08-Фев-24, 00:24
	> BTRFS в проде? > Я как-то здесь писа́л что была в эксплуатации 1 штука. А у фэйсбука - миллиард юзерей обслуживает. Это даже не война чукч и китайцев, ибо за чукч сегодня играю я: пачка btrfs'ов у меня найдется, но vs фэйсбук будет вон то. А у вас - одна. Как-то. Мне с таким раскладом ваш экспериенс - точно надо? > По той причине что идеально ложилась на задачу (снапшот снапшота снапшота, и все в RW). И вы конечно были в курсе структурального устройства btrfs и особенностей дизайна чтоб такие далеко идущие выводы делать? > Так вот, уже́ нет. Сложилась в немонтируемое состояние просто на очередном рефлинке. А вот это странно. Я довольно активно юзаю снапшоты и рефлинки. И откровенно разваливаться от этого оно не должно. Может начать тормозить если ссылок на блоки дохрена, но до этой точки догнаться - еще суметь надо. Во всяком случе с современными кернелами - если не делать глупостей - оно как-то так. Любители суперстабильных редхатов и чего там - читают список поддерживаемых конфиг, соответственно. Более того - такие заявы, имхо, либо идут с полными техническими деталями + ссылкой на баг, либо в сад. Читать все эти слезные истории без деталей - заманало. > Единственный позитив что предусмотрен механизм экспорта данных. И он таки отработал > (x5 к месту на СХД в данном случае). Лично мне это никогда не требовалось, хотя btrfs'ов у меня есть. А теперь и несколько сабжей. Для сравнения и вообще. Вот с ними были некоторые проблемы, но их уже зарулили, как вы наверное догадались. Нет, проблемы на которые наткнулся я - долго не живут. > Вытащил и перепаковал в zfs. С реальным геморроем на переписывание операций над > снапшотами (и потерей в моменте консистентности). Лично мне этот внемайнлайновый выкидыш не вперся. Я вообще не энтерпрайз и тем более не собираюсь с внемайлайн модулями бодаться. К тому же оно без подпора сотнями рамы тормоз и у него горбатый менеджмент. А btrfs на минималках живет даже на роутере с 64 мегами рамы, ему нормуль. А менеджмент этой штуки - лучшее что со мной случалось по части ФС. Кент молодец что передрал все ключевые аспекты. > Но даже так, в проде едут 20+ штук zfs. Это всё тоже сильно специфические применения, А у фэйсбука тысячи серверов. Обслуживающие миллиард юзеров. В проде. Good enough for me. Но у меня актуальные ядра, и я в курсе где девы этой штуки обитают, на -rc ловил пару приколов, но -rc на то и нужны. > Но едут, и совсем уж на ровном месте не складываются. А я не вы - и мне вон то нафиг не упало. Вместе с вашими кейсами. У меня своя голова на плечах и я могу сам все тесты для своих конфиг сделать. > * Просто там где такая специфика, нет идей устраивать гонки на перезаписи > файлов и т.п., на чём отдельные эксплуатанты фрюхи нажигаются. (Спасибо им > за это, серьёзно.) Видимо я довольно далек от тех кейсов. И для меня btrfs работает. А мне уже который год страшилки тут рассказывают. Вот в сабже еще реально отхватитоь приколов, он все же недавно в ядре и про экспериментальность не врут.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от нах. (?), 08-Фев-24, 14:12
	> А у фэйсбука - миллиард юзерей обслуживает. Это даже не война чукч на данные которых тому - совершенно наплевать. > - одна. Как-то. Мне с таким раскладом ваш экспериенс - точно > надо? да, главное веровать. Чужой экспириенс совершенно не надо. > Лично мне это никогда не требовалось, хотя btrfs'ов у меня есть. А естественно - что ценного может быть на твоих эмбедках с дрянными флэшками? Ее целиком выкидывают (и новую у другого колхозника заказывают) даже и не разбираясь почему шибкоумный шлагбаум перестал открываться. > Лично мне этот внемайнлайновый выкидыш не вперся. Я вообще не энтерпрайз и > тем более не собираюсь с внемайлайн модулями бодаться. К тому же мастер мгновенных исправлений в чужом сверхсложном коде не может собрать себе модуль. (на самом деле - дождаться пока соберется штатным скриптом) Ну ок. > А менеджмент этой штуки - лучшее что со мной случалось по части ФС. единственное что ты осилил,  говори уж правду. > А у фэйсбука тысячи серверов. Обслуживающие миллиард юзеров. В проде. Good enough поэтому если навернется сотня-другая - фейсбук даже и не заметит. И даже если котики юзера пропадут совсем - он поплачет-поплачет, и новых накачает. Другого фейсбука у него все равно нет. Этим вот мы и отличаемся от фейсбуков.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (-), 08-Фев-24, 15:34
	> на данные которых тому - совершенно наплевать. То что у тебя получается лучше чем у них... когда покажешь прод такого же масштаба, можно будет сравнить "how it performs". А сильно косячить при том масштабе FB не может "технически". > да, главное веровать. Чужой экспириенс совершенно не надо. Экспертов опеннета? Предвзятых, с BSD/проприетарным юникс бэкграундом? Умеющим все долго, дорого, хреново, монструозно, антитехнологично? С их вэем не сработавшим для них? Хороший пример! Как делать не надо. >> Лично мне это никогда не требовалось, хотя btrfs'ов у меня есть. А > естественно - что ценного может быть на твоих эмбедках с дрянными флэшками? Оно должно просто работать и не создавать сюрпризов. И по линии ФС тоже. На вопросы fsck отвечать некому. На серваках в крупном проде - тоже! Common denominator с теми ;) > Ее целиком выкидывают (и новую у другого колхозника заказывают) даже и не > разбираясь почему шибкоумный шлагбаум перестал открываться. Поэтому должно просто работать и не делать мозг. А не fsck, бжад, заниматься. > мастер мгновенных исправлений в чужом сверхсложном коде не может собрать себе модуль. Если не создавать себе проблемы, не придется их решать. > (на самом деле - дождаться пока соберется штатным скриптом) Ну ок. Я не заинтересован в монструозном внеядерном энтерпрайзном тормозе, жрущем сотни рам. Меня другие наборы свойств интересуют. ZFS не оно. > единственное что ты осилил,  говори уж правду. Мое целеполагание страшно далеко от "осилить %s любой ценой". > поэтому если навернется сотня-другая - фейсбук даже и не заметит. Повод научиться этому в своих системах для меня. Но т.к. это грузит админов и саппорт, они не могут позволить себе высокий failure rate, это денег стоит. > Этим вот мы и отличаемся от фейсбуков. Ну, я пока с btrfs'ом ничего не потерял, его структуру более-менее понимаю, а его девы вон там под боком, и я знаю какие им слова говорить если что-то идет не так. Хренли мне еще надо? А, ну, вот, погонять дизайн Кента, изучая не будет ли он мне полезен, задатки к тому есть :)
	Ответить | Правка | Наверх | Cообщить модератору

	162. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от нах. (?), 08-Фев-24, 16:03
	> То что у тебя получается лучше чем у них... когда покажешь прод такого же масштаба У тебя что - прод такого же масштаба? Нет, у тебя подкроватный серверок и десяток пердолических микрокомпьютеров. И НОЛЬ пользователей, которым твой сервис дороже своих данных и даже личных прав (их банят, унижают, но они лезут и лезут обратно). Зачем тебе решения мордокниги в таком случае? > Мое целеполагание страшно далеко от "осилить %s любой ценой". Но сказки об сотнях исправленных лично тобой багов продолжают рассказываться. Это ведь не какие-то эти ваши модули собирать. > Повод научиться этому в своих системах для меня. Просто прикрути к воротной открывалке пару сотен открывашек. И тогда она действительно не заметит что полсотни уже навернулись. > Ну, я пока с btrfs'ом ничего не потерял нет данных - нечего и терять.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (173), 08-Фев-24, 16:56
	> У тебя что - прод такого же масштаба? Нет. Поэтому если они ОК с failure rate, для меня тем более ЗБС будет! Логика. > Нет, у тебя подкроватный серверок и десяток пердолических микрокомпьютеров. На самом деле заметно больше уже. И еще виртуалки, тесты и проч. Ну и btrfs'ы на практике работают, проблем мне не создают особо. А когда пару раз были отклонения от идеала, взаимодействие с девами мне очень понравилось. Пока тут рассказывают ужастики. Классический "слушает да ест". Ну вы там вещайте, эксперты :) > И НОЛЬ пользователей, которым твой сервис дороже своих данных и даже личных > прав (их банят, унижают, но они лезут и лезут обратно). Защитник прав пользователей и благодетель с ником "нах." - это шикарно, ччерт!! > Зачем тебе решения мордокниги в таком случае? Чтобы поляну вытоптать. А ты что подумал? Кенту бы тоже кого-то жирного бы пустить на поляну стоило, но пока рано, так он зашьется под потоком багов. >> Мое целеполагание страшно далеко от "осилить %s любой ценой". > Но сказки об сотнях исправленных лично тобой багов продолжают рассказываться. Ну не сотнях - а "всех которые я знал". Их было не так уж и дофига, суммарно по всему кернелу с дюжину по разным подсистемам и дровам. Не такой уж кернел и глючный в целом :) > Это ведь не какие-то эти ваши модули собирать. А зачем мне добавлять себе проблем, особенно если дизайн не годится для моих начинаний? Нет, менять свои хотелки, предпочтения и амплуа в мои ближайшие планы не входит. > Просто прикрути к воротной открывалке пару сотен открывашек. И тогда она действительно > не заметит что полсотни уже навернулись. Черт, гений инженерии :) >> Ну, я пока с btrfs'ом ничего не потерял > нет данных - нечего и терять. Да у меня btrfs в разных сценариях есть так то. Ну вот да - постгресы я на нем не гоняю (как впрочем и на сабже) - и совершенно ниипу как оно с ними взаимодействует. Кому это интересно тот и узнает это, сам. У меня вообще на самом концептуальном уровне - отвращение к большим централизованным переросткам. Я вижу будущее иначе чем это. ИМХО, динозаврские дизайны для кодеров под стать.
	Ответить | Правка | Наверх | Cообщить модератору

7. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от n00by (ok), 07-Фев-24, 14:33
Проблемы может и серьёзные, но не критичные: потери данных, похоже, нет. Так что это хорошая новость. Выявление ошибок на данном этапе вполне нормально.
Ответить | Правка | Наверх | Cообщить модератору

	8. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 07-Фев-24, 14:37
	Потери данные были в 6.7-rc, до релиза они не дожили. На самом деле, просто кому придет в голову удалять не существующий снепшот... Это таки вопрос. Ну, а про вторую ошибку - она не сказать, чтобы легко воспроизводится.
	Ответить | Правка | Наверх | Cообщить модератору

	11. Скрыто модератором	+2 +/–
	Сообщение от Фрик из соседней пещеры (?), 07-Фев-24, 14:57
	Значит всё же что-то там есть если удалять пытаются.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:40
	> Проблемы может и серьёзные, но не критичные: потери данных, похоже, нет. Так > что это хорошая новость. Выявление ошибок на данном этапе вполне нормально. Именно. К тому же честно было помечено экспериментальным и если кто решил экспериментальный код сразу в прод - он наверное знал на что шел и имел какой-то план на всякие разные случаи?! Но тем кто использует обновиться стоит - достаточно досадные анноянсы, хоть и не фатальные как таковые, но - без них ФС все-же эксплуатировать куда лучше.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	31. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Sw00p aka Jerom (?), 07-Фев-24, 16:59
	>потери данных, похоже, нет. какова вероятность события при удалении чего-нибудь "не нужного", удалить что-то "нужное"?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	33. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 17:06
	>>потери данных, похоже, нет. > какова вероятность события при удалении чего-нибудь "не нужного", удалить что-то "нужное"? А вот на этот случай у нас как раз и есть снапшоты... там как раз можно передумать в ряде случаев. В принципе в случае CoW даже и без снапшота, если быстро спохватиться, в btrfs можно попытаться выцепить офлайн читалкой, заякорившись на более старый generation файлухи, если gc это еше не подгреб. В сабже можно вдавить ресет до того как оно синкнет это изменение в структуры, и его как бы никогда и не было :)
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Sw00p aka Jerom (?), 07-Фев-24, 17:51
	> А вот на этот случай у нас как раз и есть снапшоты... > там как раз можно передумать в ряде случаев. снапшоты вам помогу в случае ошибочного удаления "нужного", а я имел ввиду ситуацию удаления "не нужного", в следствии чего (бага конечно же) удалилось что-то "нужное", и мы это не заметим до тех пор, пока нам не понадобится то самое "нужное", а тут и снепшот сконсолидировался. > и его как бы никогда и не было :) как и всего остального накопишвегося с последнего синка.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 18:30
	> снапшоты вам помогу в случае ошибочного удаления "нужного", а я имел ввиду > ситуацию удаления "не нужного", в следствии чего (бага конечно же) удалилось > что-то "нужное", и мы это не заметим до тех пор, пока > нам не понадобится то самое "нужное", а тут и снепшот сконсолидировался. В случае CoW 1) _Вся_ истинная иерархия вообще не обязана быть видна. 2) Это означает что снести лишку может быть технически-проблематично. У меня есть уровень менеджмента, он на 1 уровень выше / и как правило не примонтирован совсем, как раз поэтому. 3) на снапшот можно поставить readonly (или изначально его так сделать). Конечно возможны какие-то совсем странные вещи, типа прямой записи в блочный накопитель - и тогда можно выбить блоки которые референснуты всеми снапшотами, и вот тут будет упс. Но... Во первых, в ядре сейчас есть опция запрета блочной записи в смонтированые тома. Во вторых, ФС можно делать с избыточностью, тогда битая копия починится из исправной. В третьих, снапшоты не замена бэкапов. Потому что "should never happen" как бы да, но лучше если на этот случай какой-то план все же будет. Потому что бывает еще сыпучее железо, баги софта, левые DMA кривым драйвером типа нвидии, и чего там еще. И против такого лома приема может не оказаться даже у самых крутых и правильных. >> и его как бы никогда и не было :) > как и всего остального накопишвегося с последнего синка. Ну тут уж сорян. Семантика полного журнала - "все или ничего". Полузаписаные и полуперезаписные файлы могут быть еще хуже. Одно дело получить файло в старом состоянии, и совсем другое если он будет наполовину новым и наполовину старым, ЭТО вообще не обязано читаться программами. А как в примитивных ФС это все работает я как-то проверил, случайно раскатав на почту ее не оч свежий бекап. И вот это обидно было без undo так то. Кому сильно надо было - перепослали, конечно, но - in place перезапись в таком случае совсем не оставляет шансов потрепыхаться, файло просто переписывается - и это никак отменить нельзя. С тех пор я предпочитаю резервировать за собой право на ошибку периодически делая снапшоты.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 08-Фев-24, 08:07
	>>потери данных, похоже, нет. > какова вероятность события при удалении чего-нибудь "не нужного", удалить что-то "нужное"? Существенно выше, чем сферический эксперт в вакууме посмотрит код и укажет, что я там проглядел. Осталось найти корреляцию с темой новости.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	126. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Sw00p aka Jerom (?), 08-Фев-24, 14:12
	> Существенно выше, чем сферический эксперт в вакууме посмотрит код и укажет, что > я там проглядел. видать члену экспертной комиссии надо пояснить выражение "вероятность события". > Осталось найти корреляцию с темой новости. стоп, коней сферических загонишь :)
	Ответить | Правка | Наверх | Cообщить модератору

	136. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 08-Фев-24, 14:49
	>> Существенно выше, чем сферический эксперт в вакууме посмотрит код и укажет, что >> я там проглядел. > видать члену экспертной комиссии надо пояснить выражение "вероятность события". Вероятность события "эксперт смотрит код" равна нулю.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Sw00p aka Jerom (?), 08-Фев-24, 15:55
	> Вероятность события "эксперт смотрит код" равна нулю. отлично, в следующей новости еще раз спрошу.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 09-Фев-24, 08:23
	>> Вероятность события "эксперт смотрит код" равна нулю. > отлично, в следующей новости еще раз спрошу. С какой целью ты задаёшь мне не имеющие отношения к теме глупые вопросы? Это такой троллинг?
	Ответить | Правка | Наверх | Cообщить модератору

9. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от anonymous (??), 07-Фев-24, 14:37
Сидел на lvm+ext4, и дальше буду сидеть.
Ответить | Правка | Наверх | Cообщить модератору

	10. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Фрик из соседней пещеры (?), 07-Фев-24, 14:54
	ext4 и так норм ресайзится,отмонтировался и в  путь. D
	Ответить | Правка | Наверх | Cообщить модератору

	30. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:58
	> ext4 и так норм ресайзится,отмонтировался и в  путь. D Ага, а если лошади по бочине как следует врезать и топить под горку то... сможете сделать 88 миль в час?!
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Фрик из соседней пещеры (?), 07-Фев-24, 17:59
	Угу с места в карьер.)
	Ответить | Правка | Наверх | Cообщить модератору

	58. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (58), 07-Фев-24, 20:24
	Это в смысле в пропасть свалиться?
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	61. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Минона (ok), 07-Фев-24, 21:52
	Back to the future.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (-), 08-Фев-24, 00:31
	> Back to the future. Ну он его не смотрел видимо - и потому не в курсе что вместо падения в пропасть - там уже мост построят :)). А вот CoW как раз позволяет очень хорошо ощутить все эти концепции. При чем на минималках даже и grub с btrfs - машина времени на минималках так то.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Фрик из соседней пещеры (?), 08-Фев-24, 05:29
	А как ещё лошалку так разогнать?Она согласно вики максимум 71 км/ч бежит.)
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	98. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 10:29
	> А как ещё лошалку так разогнать?Она согласно вики максимум 71 км/ч бежит.) Ну вот и до фрика из соседней пещеры кажется стало доходить что такой план имеет изъян :). А до например Форда и ~век назад дошло. По примерно той же причине я не буду юзать EXT4. Он сам по себе не умеет в навигацию по четвертому измерению даже если его скинуть с обрыва. И с управлением пространством хтонь непотредная, особенно на райдах.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Фрик из соседней пещеры (?), 08-Фев-24, 10:47
	ext4 для рутиных задач типа игрушек и видосиков за глаза. Реактивных лошадок пусть админы ДЦ заводят. А выхлоп в попугах это не то что меня беспокоит. Чем ты таким занят,что тебе нужны снапшоты и прочая хня? Криптокошелёк что ли оберегаешь всеми силами Ктулху? Я самое ценное что у меня на харде есть легко заного перекачаю. D
	Ответить | Правка | Наверх | Cообщить модератору

	128. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:24
	> ext4 для рутиных задач типа игрушек и видосиков за глаза. Ну вот я уже несколько перерос примитивных маздайных пользаков с кейсами вида "отклацал 200 файлов руками". И понял что линух имеет мне предложить сильно больше чем только это. Я посмотрел вокруг и не понял почему бы мне было нельзя брать на себя более масштабные задачи. Скажем билдануть пачку кернелов с небольшими вариациями, собрать эн VM, экспериментировать на рефлинкнутой "копии" 4Tb файлухи которую я пытаюсь вон тому юзеру восстановить (копировать 4 терабайта долго и дорого). А заодно можно рулить своими системами, даже железными, "в стиле виртуалок". Без вот этой долботни часами чтобы продолжить работу компа после какого-то промаха. Там где кр00той джедай возится часами, я возвращаю все как было за пару минут и могу попробовать еще раз. > Реактивных лошадок пусть админы ДЦ заводят. На самом деле если то смотрел sci-fi и понял концепцию альтернативных таймлайнов и мультивселенных с альтернативным развитием событий, он заметит что это именно оно и есть. И теперь можно менеджить свои оси так. Это просто, круто, быстро и ненапряжно - если в базовые концепции врубиться. > А выхлоп в попугах это не то что меня беспокоит. Да хрен с ним  с выхлопом в попугаях, но в ext4 нет ни машины времени, ни self heal. А вот это как бы резко выводит его из звания competitor'ов этих технологий. Не может деревянная телега в навигацию в 4-м измерении. Хоть как. Вы не можете "догнать" того кто переместился через время. Это не хорошо и не плохо, это by design. > Чем ты таким занят,что тебе нужны снапшоты и прочая хня? Я активно экспериментирую с - внезапно - линухами. Билдую кернелы, собираю виртуалки, билдую системные образа, а иногда и всякие смежные продвинутости, типа Data Recovery знакомым, в основном линуксовым (но в общем то я и с NTFS не пасую). А также много всяких забавных продвинутых вещиц, то о чем я мечтал - но не зватало скилов или времени. Вообще довольно длинный список проектов вокруг программизма, электроники и линуха со временем отрос так то. > Криптокошелёк что ли оберегаешь всеми силами Ктулху? Я самое > ценное что у меня на харде есть легко заного перекачаю. D Ну да, маздайным юзером-потребителем можно и на линухе остаться. А я предпочел эволюционировать в нечто более мощное чем это.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от User (??), 07-Фев-24, 21:50
	>> ext4 и так норм ресайзится,отмонтировался и в  путь. D > Ага, а если лошади по бочине как следует врезать и топить под > горку то... сможете сделать 88 миль в час?! Особенно забавно с учетом того, что на большинстве реальных кейсов ext4 таки быстрее, нежели например btrfs )
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	73. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–5 +/–
	Сообщение от Аноним (-), 08-Фев-24, 00:38
	> Особенно забавно с учетом того, что на большинстве реальных кейсов ext4 таки > быстрее, нежели например btrfs ) Да, от 1 бэда под libc6 система на EXT4 и правда скопытилась резко, быстро и без предупреждения - и это вовсе даже не фича была. А нормальный self heal на ext4? Ну что вы, это фантастика. А так по приколу - btrfs с bg_tree монтируется быстрее чем ext4, XFS и bcachefs. А с практической точки зрения скорость сильно зависит от того что и как делать. Особенно если ext4 врубить полное журналирование. Иначе сравнение не эквивалентное получается, то что btrfs делает является аналогом full journal - но без пеналти по записи в 2 раза. Так что для меня ext4 - это махровое легаси. Я забыл про него.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от User (??), 08-Фев-24, 07:09
	>[оверквотинг удален] > фича была. А нормальный self heal на ext4? Ну что вы, > это фантастика. > А так по приколу - btrfs с bg_tree монтируется быстрее чем ext4, > XFS и bcachefs. А с практической точки зрения скорость сильно зависит > от того что и как делать. Особенно если ext4 врубить полное > журналирование. Иначе сравнение не эквивалентное получается, то что btrfs делает является > аналогом full journal - но без пеналти по записи в 2 > раза. > Так что для меня ext4 - это махровое легаси. Я забыл про > него. Ну вот он, мастер класс по переобуванию в прыжке от экспертных экспертов - но как дышал-то, как дышал, а? Скорость! Лошади! Тыр-дыр-пыр-форманс!!11   А сейчас "и не быстрее, а медленней (это то же самое, что и "быстрее", только чуть-чуть медленней), но зато в дисциплине монтирование-на-скорость может даже и выиграть, а вот если гирю к ноге привязать - то и вовсе конкурентов нет..." И вот все у вас так.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 10:43
	> Ну вот он, мастер класс по переобуванию в прыжке от экспертных экспертов > - но как дышал-то, как дышал, а? Скорость! Лошади! Тыр-дыр-пыр-форманс!!11 "Completely missed the point...". Скорость операций наступила после того как я научился пользоваться 4-м измерением. И вот вместо копирования 4Тб чушки - я ее рефлинкаю, и получаю "как бы копию" за секунду. Вот это - скорость операций. А покажете с EXT4 такое? :) Или, вот, снапшотом можно откатить факап системы намного быстрее чем реинсталом или бэкапами. Да и врапнуть вон тот мой десктоп в воооот эту виртуалку "btrfs send" примерно так же быстро и эффективно было. И вот я тут с вами болтаю, из виртуалки с браузером, скроеной за пару минут - а изначально эта ОС была моим десктопом. > А сейчас "и не быстрее, а медленней (это то же самое, что > и "быстрее", только чуть-чуть медленней), А сейчас я навигирую в 4 измерениях - и смотрю на ваши жилкие потуги как будто вы из пещеры только что вылупились. Видите ли, кроме bulk performance есть еще более умные способы обыграть скорость операций. Но вам такие навороты ессно недоступны. Вам надо более быстрых лошадей. Ну я и спросил - а 88 миль в час - могете? Я то путешествую во времени. А вы не сможете даже тот пререквизит... и вот все у вас так.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Фрик из соседней пещеры (?), 08-Фев-24, 11:04
	4 терабайта фоточек... Не,ну,ты конечно монстр. Признаю тебя самым авторитетным пользователем.D
	Ответить | Правка | Наверх | Cообщить модератору

	130. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:30
	> 4 терабайта фоточек... Не,ну,ты конечно монстр. Признаю тебя самым > авторитетным пользователем.D Это рассыпавшаяся ФС у вооон тех. Нормальные люди это делают так: 1) Читают образ от и до. Если накопитель рушеный - более специализированными программами. 2) Делают с этого образа рабочую копию. 3) Экспериментируют над этой копией - пытаясь в идеале ее довести до моунтабельного состояния. 4) Если прокатило - цепляют ФС и лихо выковыривают несчастному пользаку фоточки и видосы. Иначе ну, не повезло, тогда что-то типа testdisk и photorec в лапки, или специализированый продвинутый софт который нащупает остатки "альтернативным парсингом". В случае btrfs такой тул прям в команду "btrfs" встроен. А для всего остального - так умеет только платный комерческий софт. Виндовый как правило. И вооон там в пункте 2 - копировать 4 терабайта по всей площади очень не прикольно. Да и требования к месту растут. А убить с трудом вычитаный образ неудачным экспериментом - EPIC FAIL.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 14:51
	Нет, не так. С посыпавшейся бтрфс/зфс ты идёшь искать бэкапы, потому что выцепить уже ничего не получится (если что и получится, то совсем не то, что надо). По твоим словам совершенно очевидно, что ты никогда с этим не сталкивался, зачем ты тогда изливаешь свои откровения?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (156), 08-Фев-24, 15:49
	> Нет, не так. С посыпавшейся бтрфс/зфс ты идёшь искать бэкапы, Маленький нюанс в том что я видел довольно много чего посыпавшегося - но btrfs в это число не входил :). Сие походу существует в основном в страшных сказках "экспертов" опеннета. И вот меня уже какой там год стращают - а оно все не сыпется и не сыпется. По моему нормальный статус кво. Заодно показывающий куда "эксперты" могут идти вместе со своей экспертизой. > потому что выцепить уже ничего не получится (если что и получится, то совсем > не то, что надо). Имеючи оффлайн парсер прямо в штатном тулките ФС то? Умеющий якориться на разные generation объектов? Ну да, куда уж нам... а чойта для остальных такое если вообще и есть - то под маздай и за бабки? :). Для сабжа такого, вероятно, нет совсем пока, даже за бабки: слишком новый. > По твоим словам совершенно очевидно, что ты никогда с этим не сталкивался, > зачем ты тогда изливаешь свои откровения? Лол, у меня btrfs'ов - на более чем сотне юнитов крутится. А также для себя довольно много где. С чем я там не сталкивался? Развейте тему. Рискнете? :) Правда юзкейсы у меня местами эзотичные - но это как раз мне специфичные баги иногда подгоняет на невытоптанной поляне. Которые и аннулируются. Или к вопросу как я научился прикидывать качество ФС и вытоптанность поляны.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 16:34
	Так тут целый перечень когнитивных искажений, неужели, не видишь? При этом, сам же и подтверждаешь, что никогда с таким не сталкивался. Ну, даже не знаю, чем тут помочь. Толку от способностей бтрфс, если она сдохла и рассыпалась от очередного бага, вызванного драйвером какой-нибудь сетевой карты? Остаётся собирать ошмётки, и, в лучшем случае, это будут неактуальные ошмётки, от которых никого проку.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 17:09
	> Так тут целый перечень когнитивных искажений, неужели, не видишь? При этом, сам > же и подтверждаешь, что никогда с таким не сталкивался. Я содержу свое железо и системы в порядке. Разбираясь с системными проблемами, а не проверяя что будет если телепать на глючном смердящем железе которому место на свалке. Так можно налететь с любой ФС. Обладатели EXT4 и NTFS которым я вынимал их добро - проверяли. С btrfs до этого обычно не доходит: вопли "csum failed" в логи очень способствуют отлову кривого железа ДО того как ситуация получит дальнейшее развитие. Так что у меня есть мини коллекция с глючным процом, планками оперативы, шнурком сата и сыпучими флехами/sd. Оно как вы уже поняли было поймано и было заменено ДО того как успело что-то развалить. > Ну, даже не знаю, чем тут помочь. Я разве просил вашу помощь? > Толку от способностей бтрфс, если она сдохла и рассыпалась от очередного бага, > вызванного драйвером какой-нибудь сетевой карты? В моих системах нет багов такого плана. Я не потерплю в моих системах такую байду, она будет загашена. И таки у меня ряд систем гоняется с несколько расширеным "self-check", по ряду причин. А такие факапы обычно ведут опять же к вою про failed csum задолго до эскалации в реальные проблемы. После чего я резко разбираюсь что за хрень творится. А вы можете смердеть на глючной системе, в надежде что-то отколупать, конечно. > Остаётся собирать ошмётки, и, в лучшем случае, это будут неактуальные ошмётки, > от которых никого проку. Эту кульную историю я слышу я уже забыл сколько лет. Очень страшно, ога. Но вы не переживайте, у меня скиллов имхо таки хватит с проблемой зарубиться. Если я понимаю дизайн и умею с девами взаимодействовать, это хорошее начало истории.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от User (??), 08-Фев-24, 13:44
	>[оверквотинг удален] >> А сейчас "и не быстрее, а медленней (это то же самое, что >> и "быстрее", только чуть-чуть медленней), > А сейчас я навигирую в 4 измерениях - и смотрю на ваши > жилкие потуги как будто вы из пещеры только что вылупились. Видите > ли, кроме bulk performance есть еще более умные способы обыграть скорость > операций. Но вам такие навороты ессно недоступны. > Вам надо более быстрых лошадей. Ну я и спросил - а 88 > миль в час - могете? Я то путешествую во времени. А > вы не сможете даже тот пререквизит... и вот все у вас > так. А полезное что-нибудь - пробовали? Ну-там postgres какой-нибудь запустить, kafka'у задеплоить и какую-нибудь нагрузку дать, PVC в RWM к куберу подключить так, чтобы кластер выключение одного сервера переживал, гигов хотя бы 500 пользакам с правами доступа раздать - ну хоть что-нибудь? А то рассказы про "четвертое измерение" и тому подобное это хорошо - но людям мал-мала работать надо. Некоторым. Иногда.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	131. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:38
	> А полезное что-нибудь - пробовали? Ну-там postgres какой-нибудь запустить, kafka'у задеплоить Так это оно для вас - полезное. А мне это все нужно и интересно - как зайцу стопсигнал. Я не DBA внезапно, и в моих проектах - вся эта монстрятина нахрен не вперлась. С чего вы возомнили что я буду оценивать технологии для ваших юзкейсов и интересоваться теми проблемами? Это ваша участь. > и какую-нибудь нагрузку дать, PVC в RWM к куберу подключить так, > чтобы кластер выключение одного сервера переживал, гигов хотя бы 500 пользакам > с правами доступа раздать - ну хоть что-нибудь? Я не занимаюсь кластерами с 500 пользаками. Это просто не моя проблематика. А вот на одноплатниках DUP с btrfs разложил, например. И это улучшило их надежность. > А то рассказы про "четвертое измерение" и тому подобное это хорошо - > но людям мал-мала работать надо. Некоторым. Иногда. Ну вот я и думаю что таких работников вообще - в шахту, уголь копать. А там гденить глядишь и парочка одноплатников пристроится до кучи, можете у олимекса посмотреть как это бывает, там с фоточками. А то поразвелось тут всяких кафкианских бездельников с базами...
	Ответить | Правка | Наверх | Cообщить модератору

	155. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от User (??), 08-Фев-24, 15:48
	>[оверквотинг удален] > и интересно - как зайцу стопсигнал. Я не DBA внезапно, и > в моих проектах - вся эта монстрятина нахрен не вперлась. С > чего вы возомнили что я буду оценивать технологии для ваших юзкейсов > и интересоваться теми проблемами? Это ваша участь. >> и какую-нибудь нагрузку дать, PVC в RWM к куберу подключить так, >> чтобы кластер выключение одного сервера переживал, гигов хотя бы 500 пользакам >> с правами доступа раздать - ну хоть что-нибудь? > Я не занимаюсь кластерами с 500 пользаками. Это просто не моя проблематика. > А вот на одноплатниках DUP с btrfs разложил, например. И это > улучшило их надежность. Ну, т.е. не пробовали. Вот почему-то ни капли не удивлен, да. В спортивной конпеляции ведра и копирования 4х гигов самому себе соревноваться не готов, простите. >> А то рассказы про "четвертое измерение" и тому подобное это хорошо - >> но людям мал-мала работать надо. Некоторым. Иногда. > Ну вот я и думаю что таких работников вообще - в шахту, > уголь копать. А там гденить глядишь и парочка одноплатников пристроится до > кучи, можете у олимекса посмотреть как это бывает, там с фоточками. > А то поразвелось тут всяких кафкианских бездельников с базами... Ну, шахта - не шахта, а вот на угольном разрезе моя система есть. Да, не "умная каска" на одноплатниках - всего лишь планирование и управление от движения карьерников до обогатительной фабрики, ну уж что есть. Может даже и тиражнется - хз.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (156), 08-Фев-24, 15:55
	> Ну, т.е. не пробовали. Вот почему-то ни капли не удивлен, да. Ну так это ваш кейс, полезный - вам. При чем тут я? > В спортивной конпеляции ведра и копирования 4х гигов самому себе > соревноваться не готов, простите. Ага, и DUP на пачке одноплатников для улучшения надежности rootfs вы тоже не сможете. Почему-то. > Ну, шахта - не шахта, а вот на угольном разрезе моя система есть. Да, не "умная каска" > на одноплатниках - всего лишь планирование и управление от движения карьерников > до обогатительной фабрики, ну уж что есть. Может даже и тиражнется - хз. Тоже неплохо. А "умные каски" разные бывают - зазырьте у олимекса куда они это привинтили и зачем. Не вижу ничего этакого в таких кейсах. При том это как раз именно апгрейд свойств машин, и на мой вкус - шаг в правильном направлении. Будущее будет таким. Кто это не поймет - тем хуже для него.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Минона (ok), 08-Фев-24, 14:25
	> И вот вместо копирования 4Тб чушки - я ее рефлинкаю, и получаю > "как бы копию" за секунду. А зачем нужна эта "как бы копия"?
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	132. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:41
	>> И вот вместо копирования 4Тб чушки - я ее рефлинкаю, и получаю >> "как бы копию" за секунду. > А зачем нужна эта "как бы копия"? Затем что при Data Recovery урыть вычитаный с мучениями образ оригинала неаккуратным действом в высшей степени обидный факап. И совсем не факт что получится читануть его с полудохлого накопителя еще раз. Ну там fsck натравить на вот именно копию - и посмотреть, получится это например смонтировать, или - как у рейзера - том совсем в вермишель? Или даже хексэдитором солнце вручную, вот, закатить попытаться, если понятно где трабл. При том fsck меняет относительно немного блоков, поэтому "якобы 4TiB" копия реально займет лишь несколько мегов нового места, а остальные блоки как в оригинале.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (36), 08-Фев-24, 14:56
	Ты не понимаешь основ криминалистической работы с данными, а это именно то, что важно и позволяет избежать дальнейших сюрпризов. Ну, это когда данные действительно представляют какую-либо ценность, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (156), 08-Фев-24, 16:03
	> Ты не понимаешь основ криминалистической работы с данными, Data Recovery != криминалистическая работа с данными, ВНЕЗАПНО! :D. В этом случае цель - выцепить для хомячка максимум добра. Обычно получается вынуть все или почти все. Хотя когда мне сильно надо - я могу и продвинутый анализ содержимого на манер форенсиков. Однако я никогда никому не обещал что мои технологии годятся для доказательств в суде. Это другая ипостась, пересекающаяся с той лишь местами. > а это именно то, что важно и позволяет избежать дальнейших сюрпризов. > Ну, это когда данные действительно представляют какую-либо ценность, конечно. Меня официальная криминалистика с ее требованиями не особо интересует, сорянчик. Я это никогда никому и не обещаю. А для себя - я таки немного умею в forensic, в основном для определения что за ж@пы вон те системы погрызли. Но это неофициально, на уровне энтузиаста информационной безопасности, а не для судов.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 01:12
	ну ты сравнил - 4x (в плохом случае 8) write amplification с 64x!
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	104. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 11:15
	> ну ты сравнил - 4x (в плохом случае 8) write amplification с 64x! При том чтобы такие цифры увидеть на практике надо быть или идиотом или нахом. И сделать что-то шедеврально тупое по смыслу, типа нагруженной БД на cow, чтоли, без nocow. А если разложить сабжа или btrfs на ноуте, воркстейшне, да даже HTTP серваке грузящем файлы каком, или чем там - найти 10 отличий от EXT4 вообще не получится. А управление ОС и местом ФС станет просто на порядок лучше. И можно будет выкинуть позор типа LVM и прочие костыли на мороз, сильно упростив себе жизнь.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 14:04
	> При том чтобы такие цифры увидеть на практике надо быть или идиотом или нахом. надо мерять. А не опрашивать. (местных неидиотов бредящих сказками о невиданых космически коро6лях бороздящих четвертые измерения)
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 14:43
	>> При том чтобы такие цифры увидеть на практике надо быть или идиотом или нахом. > надо мерять. А не опрашивать. (местных неидиотов бредящих сказками о невиданых космически > коро6лях бороздящих четвертые измерения) Очешуеть, я развел поха на здравую мысль. С которой на все 100% согласен, btw. В моих кейсах я ну вот никак не вижу отличий в дохрена VS ext4. Но это разумеется не истина в последней инстанции.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 11:29
	Сказки не рассказывай. Там разве что с CoW журнал полнее, а чтобы такой херни добиться - да даже в btrfs это уже байки из прошлого.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

13. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от Аноним (1), 07-Фев-24, 15:16
Оно умеет использовать файлы в качестве свопа или также как и ЗФС требует отдельного блочного устройства?
Ответить | Правка | Наверх | Cообщить модератору

	14. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+3 +/–
	Сообщение от Аноним (3), 07-Фев-24, 15:20
	Нет, это ж CoW. Научить можно, но я пока такое даже тестировать не хочу. А в случае с ЗФС там отдельное блочное уже давненько не требуется.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от inklesspen (ok), 07-Фев-24, 15:23
	cow можно отключить, правда на сайте автора не указано, на каком уровне он отключается: файл, устройство, фс...
	Ответить | Правка | Наверх | Cообщить модератору

	23. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:31
	> cow можно отключить, правда на сайте автора не указано, на каком уровне > он отключается: файл, устройство, фс... Примерно как с btrfs: chattr +C на пустой файл, после чего это будет nocow файло. Это достаточно универсальный интерфейс, предполагается что все cow умеющие такое - будут понимать такой хинт. XFS тоже вроде что-то такое пытался изобразить с v5 форматом.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (56), 07-Фев-24, 20:12
	> chattr +C на пустой файл, после чего это будет nocow файло Не будет. Это просто смена атрибута. man 1 chattr: A  file  with  the  'C' attribute set will not be subject to copy-on-write updates.  This flag is only supported on file systems which perform copy-on-write.  (Note: For btrfs, the 'C' flag should be set on new or empty files. If it is set on a file which already has data blocks, it is undefined when the blocks assigned to the file will be fully stable.  If the 'C' flag is set on a directory, it will have no effect on the directory,  but  new  files created in that directory will have the No_COW attribute set. If the 'C' flag is set, then the 'c' flag cannot be set.) Файл нужно создать с нуля в директории с атрибутом или пересоздать после установки атрибута - переместить между подтомами/разделами.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (77), 08-Фев-24, 01:14
	> Файл нужно создать с нуля в директории с атрибутом или пересоздать после > установки атрибута - переместить между подтомами/разделами. Так написано же: > (Note: For btrfs, the 'C' flag should be set on new or empty files. Насколько я помню для bcachefs катит практически вся btrfs'ная семантика, в том числе и это по моему. Хотя я могу и путать, ибо у меня есть оба и они в таких вещах довольно похожи. Если что под кента еще маны не переписали с его учетом. А так у меня оно есть (bcachefs и утилсы) - но как проверить какой файл по факту вышел для bcachefs? Это довольно далеко в дебри инспекции аллокации идет.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от нах. (?), 08-Фев-24, 07:22
	> А так у меня оно есть (bcachefs и утилсы) - но как проверить какой файл по факту вышел для > bcachefs? экспертиза опеннета, безжалостная ты ж с-ка... Это проверяется за пять минут совершенно банально.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 00:41
	> Оно умеет использовать файлы в качестве свопа или также как и ЗФС > требует отдельного блочного устройства? С неких пор умеет, но с довольно большими оговорками описанными в документации. ...но зачем вам в 2024 своп файлы? Чтоб истошно тупить или протирать ssd? Нарулите себе zram - это намного прикольнее: "своп" отливается в оперативу со сжатием. Заодно oom killer если что - выносит прожор секунд через 5 тупняков, а не через 5 минут, таким компом пользоваться сильно приятнее, если вы не убежденный фанат Win95 с офисом на 8 мегах оперативы конечно.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	80. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (1), 08-Фев-24, 02:06
	> С неких пор умеет, но с довольно большими оговорками описанными в документации. Мой интерес к файловому свопу сводится исключительно к вопросу использования совместно с zfs чудесной утилиты swapspace, создающей файлы подкачки динамически и избавляющей от необходимости выделять под swap файл или раздел фиксированного раздела, который всё равно 99% времени оказывается незадействованным. Но оказывается что в zfs под своп можно создавать разрежённые блочные устройства, которые дадут тот же эффект, что и swapspace. Так что вопрос со swap-файлом на zfs снимается. > но зачем вам в 2024 своп файлы? Чтоб истошно тупить или протирать ssd? Есть мнение что отсутствие свопа никак не избавляет от "протирания" ссд, т.к. файловый кэш при отключении свопа никуда не девается, и zram тут лишь частично снимает проблему. К тому же можно включить zswap, который делает то же самое что и zram.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (1), 08-Фев-24, 02:09
	> файл или раздел фиксированного раздела *размера
	Ответить | Правка | Наверх | Cообщить модератору

	109. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 11:38
	> Мой интерес к файловому свопу сводится исключительно к вопросу использования совместно > с zfs чудесной утилиты swapspace, Ну вот тут упс, я не пользуюсь ни тем ни другим - и ничего не скажу по этому поводу. На btrfs создать своп файл - можно, при том стандартной ФСной семантикой. Но - с кучей оговорок, описанных в документации. > под своп можно создавать разрежённые блочные устройства, которые дадут тот же > эффект, что и swapspace. Так что вопрос со swap-файлом на zfs снимается. На мой вкус это все звучит как-то сложно и потому - нахрен нужно. Особенно для свопа. >> но зачем вам в 2024 своп файлы? Чтоб истошно тупить или протирать ssd? > Есть мнение что отсутствие свопа никак не избавляет от "протирания" ссд, Есть мнение что попытки эмулировать недостающую оперативу SSDшником могут его прилично протереть при неудачном раскладе (OOM не наступил а свопилось долго и интенсивно). Это в общем случае рандомные 4K записи оптом, весьма неудобные FTL, потому с хзкаким amplification. Но я уже давно понял что ожидать логичный, осмысленный менеджмент систем от любителей ZFS не приходится, вместо этого будут какие-то дурацкие ритуалы на ровном месте и бабушкины сказки. > т.к. файловый кэш при отключении свопа никуда не девается, И, собственно, что? Проблема свопа в том что в него пишут мелкими 4К страницами, при душняке с памятью делая это много и рандомно - что как бы неудачный паттерн. С учетом SSD можно при случае довольно быстро его так протереть до дыр, если звезды так сложатся. Файловый кеш такой хренью в общем случае не занимается. > и zram тут лишь частично снимает проблему. Пойнт zram - компресануть "холодные" страницы, при том быстро (==лимит урону латенси при душняке с памятью) - но если они все же понадобятся, их декомпреснуть из оперативы какимнить LZ4 или LZO+RLE - быстро (==опять же латенси программ не сильно хромает). Получается система достаточно приятная в использовании. Алсо в силу сжатия может аллоцировать и поюзать больше чем физической оперативы было, в чем пойнт и состоит. При этом ничего не протирается и не тормозит особо, в самом плохом раскладе - ну, перфоманс секунд на 5 просядет до OOM killer'а, но система остается юзабельной. > К тому же можно включить zswap, который делает то же самое что и zram. Он делает не то же самое - и нуждается в IO на блочные девайсы. Некая неведома зверушка пойнт которой понимают лишь сильно некоторые эстеты. Я предпочитаю совсем кильнуть IO на блочный уровень от потуг эмуляции оперативы, так система предсказуемее и куда приятнее в использовании, и не протрет SSD случайно в неподходящий момент.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	194. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 09-Фев-24, 00:25
	>...но зачем вам в 2024 своп файлы? Есть устаревшие программы которые могут использовать своп как тмп кэш (например переводчик Правда) .Гипернация ?
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

16. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от Kuromi (ok), 07-Фев-24, 15:44
"Понеслась моча по трубам", как говаривали в одном известном фильме. Было ожидаемо, что найдется куча диких багов. Вопрос в другом - в каком же релизе ядра эти баги наконец перестанут быть дикими?
Ответить | Правка | Наверх | Cообщить модератору

	32. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от Аноним (-), 07-Фев-24, 16:59
	> "Понеслась моча по трубам", как говаривали в одном известном фильме. > Было ожидаемо, что найдется куча диких багов. Вопрос в другом - в > каком же релизе ядра эти баги наконец перестанут быть дикими? Для ФС которая с нами менее 1 релиза кернела - не такие уж и дикие баги, но с их фиксом - лучше чем без.
	Ответить | Правка | Наверх | Cообщить модератору

17. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от Mr.Who (?), 07-Фев-24, 15:45
Оно метит в гильдию ибийц ZFS?
Ответить | Правка | Наверх | Cообщить модератору

	20. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (-), 07-Фев-24, 16:15
	А почему бы и нет? Вот за столько лет openzfs стала надежной и стабильной? А не за сколько, ахаха, с ней до сих пор данные теряются!
	Ответить | Правка | Наверх | Cообщить модератору

	35. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от нах. (?), 07-Фев-24, 17:14
	> А почему бы и нет? > Вот за столько лет openzfs стала надежной и стабильной? > А не за сколько, ахаха, с ней до сих пор данные теряются! Но они там не теряются из-за попытки удалить несуществующую фс, даже если ты упор(ен) и сделаешь это дважды. И она не крэшит ядро из-за закрытия файла. Чтобы именно потерять данные - надо в ней сделать с пулом какую-то очень стремную операцию, и, как правило, одновременно дернуть питание. И даже в этом случае тебе должно еще и сказочно неповезти - пришедшие к успеху обычно не один раз такое сделали.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 18:41
	> Но они там не теряются из-за попытки удалить несуществующую фс, даже если > ты упор(ен) и сделаешь это дважды. Не ФС а subvol. Subvol - это дерево, типа директории. Точка входа. Просто менеджится независимо от остального, тепер в ФС может быть более 1 / что и делает всякие снапшоты и проч удобными. Случай когда пытались грохнуть именно subvol, да еще не существующий, дважды - все же при практических сценариях достаточно специфичный, и встречается не часто. Ну вот кто-то релиз кернела спустя все же попытался странного - и получил еще более странный локап в файлухе. Что как бы баг. Но как бы ни к чему кроме матюков неудачника вроде не ведет. > И она не крэшит ядро из-за закрытия файла. > Чтобы именно потерять данные - надо в ней сделать с пулом какую-то > очень стремную операцию, и, как правило, одновременно дернуть питание. Вот именно в случае CoW - дерг питания обычно приводит дизайн в несколько более старое состояние и профакивается только то что не было синкнуто, тут уж пардон. А вот сломать CoW сам по себе именно так - весьма экзотично. Разве что если сломается еще и фирмвара накопителя и профачит допустим Eraseblock - а вот тут уже мало кто готов к тому что чушку в 16...64 мега целиком пролю, за то что "те данные лежали в этом регионе". Это нарушает семантику - но на SSD так то нельзя сдергивать питание в произвольный момент времени, это нарушение их условий эксплуатации и логиится в смарт. > И даже в этом случае тебе должно еще и сказочно неповезти - пришедшие > к успеху обычно не один раз такое сделали. У меня есть накопитель где внеплановые шатдауны более 100 раз были - а btrfs там так и не помер. Видимо не оч кривая фирмварь и ворочание eraseblock'ов сделано относительно вменяемо.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+3 +/–
	Сообщение от нах. (?), 07-Фев-24, 19:06
	> Не ФС а subvol. Subvol - это дерево, типа директории. директория - это французское правительство времен контр-революции. А в zfs аналог ваших "subvol" - filesystem. > Случай когда пытались грохнуть именно subvol, да еще не существующий, дважды - все же при > практических сценариях достаточно специфичный банально опечатался, получил ошибку, не понял в чем дело и повторил команду. Или того проще, ошибка в скрипте вычисляющем имя того что нужно удалить, и оно всегда одинаковое получается. Судя по тому что сразу же и нашли - то либо другое у кого-то и было. А вот случаи когда люди прямо совсем необратимо теряли пулы zfs - это действительно несчастные случаи. Трудно назвать счастливчиком человека, который при восстановлении _уже_ поврежденного громадного пула ловит внезапно попадание молнии в трансформатор. (Да, он в принципе зря стал это делать, но полагаю у него просто не было столько лишних денег на второй такой же.) > Вот именно в случае CoW - дерг питания обычно приводит дизайн в несколько более старое > состояние и профакивается только то что не было синкнуто а теперь представь что это операция не банальной записи пары бит в конец файлика, а реконфигурация всей системы. Точно-точно ли при этом можно профакать то что не было синкнуто, особенно с учетом привычки дисков к write reordering? Авторы zfs вот видимо думали что можно. Оказалось - нельзя, ну или во всяком случае в текущем состоянии кода нельзя, а способных его чинить уже нет. Ну и отсутствие fsck таки очень плохая, вообще никуда негодная идея, разумеется - вытекающая из предыдущей неверной гипотезы.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от PnD (??), 07-Фев-24, 22:13
	В btrfs местный fsck тоже примерно полностью нерабочий. О чём, впрочем, авторы честно предупреждают. Зато есть механизм экспорта данных через разматывание журнала от начала до точки слома. Этого (или хотя бы внятного инструмента отката указателя, hexedit не предлагать) в современной zfs реально не хватает. * А вот reflink в последнем выпуске, внезапно, осилили. Минус 1 повод поканючить о продолбанных компетенциях.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 01:17
	txg можно откатить без хексэдита (ее, правда, угадать тот еще гемор). Ходят слухи что это кому-то даже помогало импортировать неимпортящийся пул хотя бы в r/o и слить данные. > А вот reflink в последнем выпуске, внезапно, осилили. они там даже добавление в raidz6 (который целиком неосилен линуксятками) осилили, чего я от них совсем не ждал. (правда оно малость кривоватое, но это можно считать фичей)
	Ответить | Правка | Наверх | Cообщить модератору

	100. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (100), 08-Фев-24, 10:38
	> они там даже добавление в raidz6 (который целиком неосилен линуксятками) осилили, чего я от них совсем не ждал. (правда оно малость кривоватое, но это можно считать фичей) А можно поподробнее?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 13:53
	>> они там даже добавление в raidz6 (который целиком неосилен линуксятками) осилили, чего я от них > А можно поподробнее? https://github.com/openzfs/zfs/pull/15022#issuecomment-18024... Я даже предлагал местным горе-писакам запилить про это новость (когда она еще была - новостью) но им неинтересно, то ли вот дело про ненужный скрипт на ненужном язычке - это куда важнее.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (-), 08-Фев-24, 14:48
	> Я даже предлагал местным горе-писакам запилить про это новость (когда она еще > была - новостью) но им неинтересно, то ли вот дело про > ненужный скрипт на ненужном язычке - это куда важнее. Просто для понимания - некий анон наколотил про сабж основные тезисы для Чиркова. Так появление новости заметно вероятнее. Это такой возврат техдолга Кенту и тем продвинутым, кто вместе с нами создает будущее, не боясь изучать новое и экспериментировать. Твой путь и твоя версия будущего отличаются от того что я хочу видеть - и это твоя участь создавать его, или бесславно слить, если тебе так удобнее. Мне ZFS не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 14:53
	> Просто для понимания - некий анон наколотил про сабж основные тезисы для Чиркова. ну мне было лень стараться (потому что все что я хотел бы увидеть - и так было по ссылке, а копипастой мне неинтересно заниматься) в этот раз (все равно обычно мои новости не публикуют as is, а после замены всего мата обтекаемыми выражениями становится неясным о чем новость) Тем более что я ни тем ни твоим кентам ничего и не задолжал. А опеннет давно уже не про новости а про т-пой троллинг и скрипты удаляющие сообщения методом рандомного тыка.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 16:28
	>> Просто для понимания - некий анон наколотил про сабж основные тезисы для Чиркова. > ну мне было лень стараться (потому что все что я хотел бы > увидеть - и так было по ссылке, а копипастой мне неинтересно > заниматься) в этот раз (все равно обычно мои новости не публикуют > as is, а после замены всего мата обтекаемыми выражениями становится неясным > о чем новость) А я решил оставить себе подобным месадж - "стоит обновить кернел", если они юзают вон то. Надеюсь спасет их от пары грабель. Мой интерес в этом? "А зачем мне багованая файлуха?!". Вот зачем небагованый современный CoW дизайн - придумаю эн вариантов. В идеале сие простимулирует кого-то присоединиться к процессу. > Тем более что я ни тем ни твоим кентам ничего и не задолжал. Это моя персональная дань уважения упрямому чуваку на самом деле. Если я могу сдвинуть мир на миллиметр в его пользу - something to chew on! > А опеннет давно уже не про новости а про т-пой троллинг и > скрипты удаляющие сообщения методом рандомного тыка. Ну вот бот подбешивет, да. И все же - если тебя интересует направление и его взлет логично в этом участвовать. Ну или кто это должен делать? Мне ZFS с его свойствами - просто не требуется. Тратить время на технологию которой не пользуешься странная идея. Тем более что так легко нагнать с 3 короба.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 12:26
	> директория - это французское правительство времен контр-революции. Вот оно что! Юниксоиды - буржуазная контра стало быть?! > А в zfs аналог ваших "subvol" - filesystem. А ты уверен что 100% аналог? Скажем новый снапшот ZFS - будет технически именно новым filesystem в тех терминах? Или скажем filesystem можно удалить через системные вызовы? Ну там rm обычным и проч? Снапшоты (и сабволы вообще) btrfs/bcachefs можно отменеджить не только родной утилсой - но и просто F8 в миднайте каком. Поскольку это в принципе лишь независимая иерархия, нет особых проблем ее - снести, как диру почти, с довольно небольшими отличиями. > банально опечатался, получил ошибку, не понял в чем дело и повторил команду. Ну вот видимо кто-то и заметил что фигня какая-то получается. Фигня досадная но не фатальная. > Или того проще, ошибка в скрипте вычисляющем имя того что нужно удалить, Я бы в общем случае побаивался юзать скрипты с ошибкой вычисления сносящие subvol, имхо. Хотя любителям bumblebee понравится. Особенно если у...ть нужный снапшот (для аутентичных ощущений). > Судя по тому что сразу же и нашли - то либо другое у кого-то и было. Ну как бы у линя довольно много пользователей, кто-нибудь из них да отколет что-то странное. > А вот случаи когда люди прямо совсем необратимо теряли пулы zfs - Так там речь о потере данных вообще не идет. Только о обидном локапе в кишках фс. > (Да, он в принципе зря стал это делать, но полагаю у > него просто не было столько лишних денег на второй такой же.) Ну я вот как-то рестрайпил некий btrfs - и питание улетело. Технически примерно то же самое по смыслу. В общем случае balance являет собой недеструктивную операцию. Конечно любое кантование данных несет некие риски, но т.к. cow сперва создает копию а потом "указатели перевешивает", крах в общем случае не вызывает больших проблем. То что записалось сохраняется, то то не записалось авто-отменяется за отсутствием "указателей" на это. А сам дизайн нормально относится к смеси разных типов block groups, ну ему и пофиг было. Прекрасно маунтится и работает, так что пнуть операцию еще раз - он и доконвертит что еще не успел. Мне вот повезло - flawless conversion, даже после poweloss. Scrub никаких траблов не увидел и все как часики. Со своей стороны я считаю что управление ФС должно быть - ну вот как-то так, имхо. > а теперь представь что это операция не банальной записи пары бит в > конец файлика, а реконфигурация всей системы. Если я что-то такое затеваю - тебе не приходило в голову что снапшот по его смыслу это такой мануальный "barrier" на тему состояния ФС в этой точке пространства времени? Я сигналю что считаю это состояние ценным. Это мой key frame в таймлайне. Я требую его не разрушать GC, чтобы иметь возможность на него вернуться. ...а после этого можно хоть "eatmydata apt upgrade" влупить, и если он даже сгорит синим пламенм, мне совершенно не важно что там отъедет, я снапшот "атомарно" в старое состояние верну вместо колупания в деталях факапа. Сэкономив дочерта времени на парировании проблемы. А потом можно попытаться операцию еще раз. "All or nothing" можно заимелементить совместной игрой с машиной, так сильно эффективнее. Ибо я лучше знаю определения "all" и "nothing" в этом контексте. > Точно-точно ли при этом можно профакать то что не было синкнуто, особенно > с учетом привычки дисков к write reordering? Если команды сброса буферов работают как должны, то само по себе это имхо не проблема. А если нет - там с любой ФС при случае гамна можно будет откущать ибо они ВСЕ на эту семантику уповают. Есть еще всякие совсем левые вещи - типа продолба eraseblock который in-flight при powerloss, но вот тут - сорян, если чушка в 16-64 мега испарилась, любая ФС может дать дуба. У особо неудачливых, с голимым накопителем, глупой фирмварой и неудачным расположением - вместе с партишном заодно. А те кто поумнее догадываются отступить на флешатине от начала девайса достаточно почтенный 2^N (64MiB или более) чтобы партинш в своем eraseblock'е лежал и его не ворочали лишний раз. Т.к. там interleave, это erase group на самом деле, его могут ворочать весь сразу, и он крупнее 1 eraseblock'а, откуда и округление. В случае "испарения чушки" очень кстати если была избыточность, даже DUP даст нехилые шансы потрепыхаться. По той же причине суперов и у кента и у бтрфс несколько. Что-нибудь да выживает, а дальше self heal по полной версии задумки. На практике - в btrfs рековери суперов таки маниуальная операция. Но вроде недавно таки сделали и опцию автоматически чинить убитый основной супер из запасных. > Авторы zfs вот видимо думали что можно. Оказалось - нельзя, ну или во всяком > случае в текущем состоянии кода нельзя, а способных его чинить уже нет. Вообще фирмвари накопителей делают очень много всякой весьма странной фигни, там дочерта quirks, out of spec поведения и левизны. Ну вон у самса например были траблы с trim, вплоть до того что это могло девайс угробить. Не по спекам, но юзеру с дохлым девайсом же не объяснишь, он будет вопить что это ацтой. Имея некий пойнт. Так что там костылей в libata и проч - очень даже. У btrfs'ников кстати описаны "типовые" факапы сторажей в их доках, по их опыту. > Ну и отсутствие fsck таки очень плохая, вообще никуда негодная идея, разумеется > - вытекающая из предыдущей неверной гипотезы. С практической точки зрения - на серваках - да и моих одноплатниках - этот fsck запускать решительно некому. Так что это как баг - так и фича. Ибо дочерта систем работает, натурально, в режиме автопилота. И там мы хотим self heal до последнего - пока это можно, с диагностикой и статистикой. А потом - потом система потребует мануальное внимание и это mission failed что так что сяк, детали уже не очень важны. Железки стояли не для того чтобы там fsck запускали. Вообще совсем.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	42. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Mr.Who (?), 07-Фев-24, 18:05
	ZFS с самого начала была железобетонной по надёжности. Что в Соляриса, что потом во вряхе. Только в линуксе оно работает через жопэ, но это уже не вина ФС.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	49. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (49), 07-Фев-24, 18:34
	Но вы же её пытаетесь использовать в linux. Поэтому неважно, где проблемы, важно, что они есть.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от нах. (?), 07-Фев-24, 19:14
	> ZFS с самого начала была железобетонной по надёжности. нет. > Что в Соляриса, что потом во вряхе. История с крэшем который _разработчики_ (во всяком случае - мнящие себя таковыми) _отказались_ даже пытаться исправлять - была именно во фряхе во времена ее собственной реализации. История с #ifdef solaris  ВМЕСТО исправления ситуации с неработающим memory pressure и глухим отказом принимать работающий во фре отлаженный и протестированный кучей людей код - там же и тогда же. > Только в линуксе оно работает через жопэ, но это уже не вина ФС. это вина тех кто считает себя ее разработчиками. (других разработчиков у меня для вас нет) "ой мы открыли диск с O_EXCL и теперь не можем изменить размер тома потмоу что ну вот же вот" - тоже очень показательная.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	21. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Tron is Whistling (?), 07-Фев-24, 16:26
	Оно метит в гильдию убийц _вместе_ с ZFS. Убийц _данных_.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	65. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от PnD (??), 07-Фев-24, 22:35
	ext3 и ext4 здесь вне конкуренции. Кто-то может сказать что я не прав и f2fs ещё веселее. Но кто её массово в проде использует? xfs несколько лучше, т.к. контролирует хотя бы метаданные и есть шанс отреагировать до того как на месте ФС останется фарш. (Недавно так поймал начало процесса осыпания *зеркала* из пары НЖМД. До этого там ехала ext4, успевшая рассыпаться в труху до ухода в RO. А на xfs успел-таки поймать начало процесса. Прогнал проверку rpm по контрольным суммам, и даже кластеризовал осыпающееся по inod'ам.) Фишка CoW ФС — в возможности реплицировать журнал. И в момент X остаться не совсем уж у разбитого корыта. Но не бесплатно, конечно. Нужна ли именно CoW, или есть более подходящие механизмы — вопрос конкретного применения.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 07-Фев-24, 23:13
	ext4 тоже метаданные научилась контролировать. Справедливости ради.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (-), 08-Фев-24, 12:36
	> ext4 тоже метаданные научилась контролировать. Справедливости ради. Знаете что такое too little and too late? Это вот оно. Вон там пара команд уже звездные крейсеры построили. А тут - вау, пороховую ракету к фанерному биплану приделали. Выглядит угарно - но на звездный крейсер все же по совокупности фич не тянет. И так то с учетом теорвера - у данных площадь намного больше. Так что можно довоьлно долго не замечать факап. Более того - ну вот заметил я CRC error. И чего? Вон те интегрированые дизайны - попросят вторую реплику с другой копии, из нее починят битое. SELF HEAL. А ext4 чего сможет в общем случае? Сообщить что он теперь - тыква? Вау, ну спасибо, ценное знание. А чтоб осмысленный self heal из другой копии, при том более-менее, прозрачно, эффективно, только битого сегмента - это надо видите ли интеграцию ФС с механикой райда было... а это не про античного classic уродца. Он быстро бегает. Местами. На этом его достоинства заканчиваются. И то - создаете диру с 100К филезов. Не, это конечно не такая ж как ntfs, но, знаете, даже btrfs поприятенее в этом аспекте. EXT4 к тому же не умеет деаллокацию раздутых дир и они такие и остаются - навечно. Даже если я стер большую часть файлов, судя по скорости операции оно потом ради 100 файлов будет весь тот шмат ворочать. А сдуть только мануально, пересоздав диру и мувнув файлы. Как ни странно этот момент подхайлайтил похонах, мне стало интересно - я понаблюдал - и кажется этот булшит в EXT4 имеет место по сей день. Что как бы фэйспалм.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 09-Фев-24, 01:13
	>деаллокацию раздутых дир и они такие и остаются - Делается,но вручную,есть ключ для tune ,только на размонтированном разделе, применяется в особо тяжёлых случаях (навскидку не скажу,нужно искать ,специфичный ключ).Да,анохроизм.Но в 90% при дефрагментации  так раздутые метаданные чистятся .
	Ответить | Правка | Наверх | Cообщить модератору

	202. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 09-Фев-24, 11:16
	>>деаллокацию раздутых дир и они такие и остаются - > Делается,но вручную,есть ключ для tune ,только на размонтированном разделе, Я очень рад за фанатов EXT4 - вот пусть они этой порнографией и занимаются! А я такие непотребства с ФС да еще с размонтированием - в гробу видал, скажем прямо. Я не желаю рулить моими ФС и системами в таком стиле. Это добро должно работать и решать проблемы. А не делать мозг и создавать новые проблемы изниоткуда. > применяется в особо тяжёлых случаях (навскидку не скажу,нужно искать , > специфичный ключ).Да,анохроизм.Но в 90% при дефрагментации  так раздутые метаданные чистятся . Я почистил путем миграции на btrfs, так гораздо прикольнее по сумме свойств оказалось. И не надо мля мануально танцевать с майнтенансом загаженых дир, блин. Да, я иногда могу вывалить 600К файлов в одну диру. Скажем при датарекавери какимнить photorec. И мне что - потом мануально каждый раз это сдувать? Или наслаждаться характерным "перфомансом" операций с дирой? Делать мне больше нехрен. Не понимаю смысла делать из проблем этого скелета свои проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 07:19
	> ext3 и ext4 здесь вне конкуренции. ext3 да, уверенно держит чемпионскую медальку. На ext4 БЕЗ журнала я за пятнадцать лет потерял НОЛЬ байт (и с журналом тоже, но он мне - не нужен). Включая жизнь с интересной платой, имеющей привычку виснуть при попытке нагрузить ее встройку. Т.е. с перезагрузками ресетом раз в пару недель минимум. Где вы берете такое барахло на котором сами по себе подменяются данные, с какой помойки? Фишка CoW fs - в 64x write amplification. И zfs мы любим вот совсем не за это.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	107. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (3), 08-Фев-24, 11:31
	Ошибка выжившего. Без журнала от внезапных резетов всё сыплется, но тебе, видимо, везло. А сабж ещё и ECC на уровне ФС предлагает (пока что жутко экспериментально и не стабильно, но всё же заявка хороша).
	Ответить | Правка | Наверх | Cообщить модератору

	111. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 12:15
	Ну сыплется не сыплется, но вот часами ждать пока fsck отработает действительно не очень. Странный тип.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 13:39
	> Ну сыплется не сыплется, но вот часами ждать пока fsck отработает действительно > не очень. Странный тип. просто пользуюсь, а не фантазирую о каких-то там "часах"
	Ответить | Правка | Наверх | Cообщить модератору

	133. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 14:41
	Ты не из тех ребят с 10 гигабайтным продом, они ещё зфс очень любят? Без журнала рекавери и поиск ошмётков действительно вечность занимает, а это даунтайм.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 14:55
	Если у тебя проду понадобилась рекавери - и ты еще плачешься про даунтайм - у тебя в подвале все плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 15:02
	Даже при наличии резерва (а он необходим далеко не везде и не всем) нет гарантий, что сейчас что-нибудь не случится и с ним. Не понимаю суть претензии.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 15:22
	Ну раз не необходим - еще подождут. Пааадумаешь. Оно уже все равно легло, пусть диск нормально теперь проверит.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 15:38
	Я проверял, с журналом fsck на ext4 отрабатывает практически моментально. При повреждении журнала надо всё отсканировать и проверить, да ещё перезапуститься несколько раз из-за ошибок. Зачем умножать даунтайм и повреждения? Это ещё не говоря о том, что без журнала будет производительность ниже, чем у ext2 (а ext4 это одна из наиболее производительных и эффективных фс так-то).
	Ответить | Правка | Наверх | Cообщить модератору

	157. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 15:50
	с журналом fsck на ext4 у тебя "отрабатывает" ровно никак. Просто завершается ничего не проверяя. Что, кстати, нифига не хорошая идея. > Это ещё не говоря о том, что без журнала будет производительность ниже, чем у ext2 лол... Все что надо знать об экспертизе опеннета.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 16:21
	> ничего не проверяя. Вообще-то, проверяет, консистентность журнала и восстанавливает данные приводя их в работоспособное состояние, а так же оперативно устраняет повреждения не отражённые в журнале. Разницы никакой, я проверял: если что не так, журнал использоваться не будет. > лол... Все что надо знать об экспертизе опеннета. Экспертиза не экспертиза, а я лично гонял тесты на ссд (не синтетику). И время доступа растёт, и задержки, там ещё что-то с производительностью создания/удаления файлов. Поэтому всегда смешно встречать таких любителей отключить журнал.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	169. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 16:36
	> Вообще-то, проверяет, консистентность журнала Его проверит обычный mount. Собственно, если у журнала нет (обнаружимых) внутренних повреждений - на этом все проверки и закончатся, fsck ничего дополнительно проверять и не будет, если специально не попросить. В современных модных systemd/linux его и вызывать-то не принято. А вот зря. > Экспертиза не экспертиза, а я лично гонял тесты на ссд (не синтетику). И время доступа растёт, и > задержки, там ещё что-то с производительностью создания/удаления файлов. Ну вот когда я такое увижу (надеюсь, никогда) - полезу проверять как это так удалось что две записи у тебя быстрее чем одна. И пока не выясню схренали - пожалуй, воздержусь от обнародования результатов.
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	176. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 17:13
	А проверки данных и не нужны на практике, журнал это самая надёжная часть фс и она защищает метаданные в первую очередь. Там не бывает повреждений, если их нет. Записываемые данные могут быть повреждены (у меня так .bash_history рута улетел ровно 1 раз), а самые последние данные вообще исчезнуть (спасибо data=writeback), но игнор журнала тут никак не поможет. Не было там двух записей, да и откуда им взяться на чтении? Разница настолько очевидна, что не возникает никакого желания продолжать эксперименты дальше. Я скорее спишу твои успехи на то, что измерения были с грубыми ошибками (а в ряде применений действительно наблюдалось незначительное повышение производительности).
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	178. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 17:43
	> А проверки данных и не нужны на практике пааанята. (правда fsck проверяет все же метаданные а не данные, но это уже неважно) > Не было там двух записей, да и откуда им взяться на чтении? Разница настолько очевидна, что я бы прямо сразу заподозрил ошибку эксперимента. Поправил, не благодари. Потому что журнал вот вообще никак не может повлиять на скорость _чтения_. И раз разница "очевидна" а ты не сделал из этого правильный вывод - грош цена твоему экспериментаторству. А вот с записью все не так однозначно и я склонен приписывать (ту, раннюю, истинную) #12309 именно журналу. (нет, пруфов нет - это сильно запоздалая догадка)
	Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

	179. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 18:03
	> пааанята. (правда fsck проверяет все же метаданные а не данные, но это > уже неважно) Абсолютно бесполезны, даже если на уровне фс повреждения записи удалось избежать (не удалось), оно с большой вероятностью будет на уроне приложения. >журнал вот вообще никак не может повлиять на скорость _чтения_. Не знаю, где ты тут увидел скорость чтения, я говорил про скорость работы с метаданными и тут возможны различные объяснения. То, что такой функциональности нет в коде, ничего не означает.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	181. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 18:11
	> Абсолютно бесполезны, даже если на уровне фс повреждения записи удалось избежать (не удалось), то продолжать работать на неконсистентной фс - так себе идея. А приложение потом отдельно разберется со _своими_ проблемами. А не они вылезут в виде внезапного крэша через пару месяцев. > Не знаю, где ты тут увидел скорость чтения, я говорил про скорость работы с метаданными и тут > возможны различные объяснения. ошибка экспериментатора - первое из них. (второе - какие-то совершенно дикие ошибки в коде фс. Так тоже бывает. Но в данном случае экспериментатор проверен своей бестолковостью и верой в чудеса, поэтому первый вариант выигрывает.)
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	185. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 18:21
	Почему, сразу, ошибки? Да ещё в коде фс? Я бы поставил на сайд-эффекты, которые достаточно просто обнаруживаются при корректно построенном процессе исследования. А вот хамить не обязательно, и хамство твою точку зрения никак не подкрепляет.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	193. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 21:49
	> Почему, сразу, ошибки? Да ещё в коде фс? "давайте думать о человеке хорошо!" (нет, но предположить же ж можно) > Я бы поставил на сайд-эффекты я тоже. Но тут всю систему менять надо. Потому что каждый может облажаться в экспериментах, но не каждому дано настолько быть незамутненным, что даже не попытаться поискать причину, а тут же возвести в ранг непреложных истин что алмаз может быть расколот только с помощью козлиной мочи. И не проси меня уважительно относиться к подобным персонажам их их очень обоснованным мнениям. Не стоят они того. (да и сами ни к кому уважительно отродясь не относились)
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	120. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 13:44
	> Ошибка выжившего. Без журнала от внезапных резетов всё сыплется, и да, расскажите уже кто-нибудь этим.... нет цензурного слова - ЧТО на самом деле меняет журнал и для чего его придумали. > везло. А сабж ещё и ECC на уровне ФС предлагает (пока чтоб еще больше тормозило? Ну ок. > что жутко экспериментально и не стабильно, но всё же заявка хороша). причем заявка от людей ниасиливших raid6 и добившися невиданных успехов в виде performance hit вместо 2x gain на raid1. Безусловно уж костыль-то в виде какого-то там ECC на уровне fs у них точно получится нормально.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	141. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–2 +/–
	Сообщение от Аноним (3), 08-Фев-24, 14:57
	>и да, расскажите уже кто-нибудь этим.... нет цензурного слова - ЧТО на самом деле меняет журнал и для чего его придумали. Придумали как раз таки для внезапных отключений питания. Прикинь, да? А сыплются без журнала - метаданные. Экспертиза она такая... опеннетная. >чтоб еще больше тормозило? Ну ок. Ты, видимо, на кривые накопители не нарывался. Ну и пусть тормозит себе (спойлер: нихера оно не тормозит), зато данные вытащить в каком-нить хреновом сторадже становится зачастую проще. >причем заявка от людей ниасиливших raid6 и добившися невиданных успехов в виде performance hit вместо 2x gain на raid1. Ваш RAID6 не особо технически лучше, а иногда и хуже RAID5. И где это Кент его вообще пытался осиливать? Ну то есть ты где-то звон слышал, но не в курсе, ога. btrfs и сабж всё же разные вещи, но ты как классический гопник, меряешь всех по себе и под одну гребенку, похоже. >Безусловно уж костыль-то в виде какого-то там ECC на уровне fs у них точно получится нормально. Ты знаешь будущее? А сколько биткойн будет стоить в конце года? Мне закупаться или продавать?
	Ответить | Правка | Наверх | Cообщить модератору

	170. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 16:49
	>> и да, расскажите уже кто-нибудь этим.... нет цензурного слова - ЧТО на самом деле меняет >> журнал и для чего его придумали. > Придумали как раз таки для внезапных отключений питания. Прикинь, да? А сыплются я все же надеюсь что нет, в нулевые годы уже умели в UPS там где важно. Скорее для внезапных крэшей и перезагрузок ресетом. Вот их у неудачников бывало и упсом это не подопрешь. И придумали для банальной экономии в этом случае времени. Не для надежности (про нее вообще ухитрились забыть и забить на пять лет), не для скорости - для экономии времени перезагрузки после крэша. Безусловно это было нужно и важно... тем кто придумал. А вот тебе - не факт. Раз ты любишь подглядывать как там у больших - вот, обрати внимание - гугль. Гугль не любит крэшащиеся системы. Вот вообще, независимо от того как быстрабыстра они перезагрузились. У него есть фэйловер. И проблему электропитания для себя решил на корню, прямым подключением к ГЭС. > Ты, видимо, на кривые накопители не нарывался. Ну и пусть тормозит себе Нарвусь - выкину. Зачем мне накопитель на который пишут одно а он возвращает нечто другое? Я вполне счастлив с такими которые читают потом то что было записано. > (спойлер: нихера оно не тормозит), зато данные вытащить в каком-нить хреновом > сторадже становится зачастую проще. Накопитель, запоровший тебе один блок, с тем же удовольствием запорет тебе и два подряд. > Ваш RAID6 не особо технически лучше, а иногда и хуже RAID5. И о б-жечки... опять экспертиза опеннета, да что ты будешь делать. Ну конечно два диска подряд отказать не могут (да и откуда они в твоих гаражных поделках, там единственная флэшка и та, похоже, из мусорки). Особенно когда и так ушатанный массив приходится прочитать-записать целиком, возможно параллельно с рабочей нагрузкой. > где это Кент его вообще пытался осиливать? Ну то есть ты т.е. заранее признал свою беспомощность. То ли дело вот ECC. Хоть 3way mirror-то есть, боюсь спросить? А то при физическом отказе пары spinning rust - ecc не очень поможет.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 18:16
	>. Скорее для внезапных крэшей и перезагрузок ресетом. Вот их у неудачников бывало и упсом это не подопрешь. Ну причины могут быть разные. Да, так то явно когда запиливали - беспокоились не о питании, а о внезапном резете. Согласен. >Не для надежности Вау. Это прям эксперт уровня "бог". Для надежности, дорогой ты наш. Для надёжности, наличие журнала значительно уменьшает вероятность повреждения ФС при внезапном отвале накопителя. И даже на оффтопике NTFS было резетами сильно труднее убить, чем FAT32. Журнал не для экономии времени введён, на время в таких случаях всем похрен, как раз таки. >Раз ты любишь подглядывать как там у больших - вот, обрати внимание - гугль. Блин. Если у тебя будут задачи как у гугля - ну вперёд и с песней, делай как у гугля. Файловер он не всегда экономически оправдан даже. И кластеры чаще всего нахер не нужны: есть бэкап. Но вот у меня лежит в бэкапе петабайт данных и на проде хранилка на 500 гиг. Если она просто рассыплется - я восстановлюсь из бэкапа, ну несколько суток полежит. А если у меня рассыплется ФС и потом восстановится - я просто проверю консистентность данных. Еще одну такую хранилку ставить, балансировку нагрузки и т.п. - это стоит столько, сколько ты не зарабатываешь, дитятко. Там цены начинаются от твоей зарплаты за 10 лет. И файловер там обеспечивается на другом уровне, но иногда и файловер не вывозит. Ты бы, кстати, поинтересовался, как у гугла устроено... :D. Помню я , как амазон со всеми его файловерами лежал. >Нарвусь - выкину. Зачем мне накопитель на который пишут одно а он возвращает нечто другое? Так ты ж, болезный, этого не узнаешь. Ибо о таком аспекте ИБ как "целостность" ты даже не в курсе, видимо. >Накопитель, запоровший тебе один блок, с тем же удовольствием запорет тебе и два подряд. Я меняю накопитель. Но для этого надо узнать, что он сдох. А он может этого и не показывать... Так что ты опять пальцем в ж... >Ну конечно два диска подряд отказать не могут Ну если в твоем массиве не больше 4 дисков... А если у меня дисковая полка с сотней дисков? ТОже предлагаешь RAID6 использовать? Мне как-то, что RAID5, что RAID6. Вот вообще плевать. Ты щас показал свою "экспертность". RAID6 он на больших объемах несколько хуже. Но я и RAID5 не использую, ибо хоть и простой как пробка, но нафиг-нафиг. >т.е. заранее признал свою беспомощность. У меня для тебя плохие новости... Сходи к психиатру: проблемы с причинно-следственными связями это серьезный симптом. >Хоть 3way mirror-то есть, боюсь спросить? А то при физическом отказе пары spinning rust - ecc не очень поможет. Там можно указывать ЛЮБОЕ количество зеркал для конкретных данных. Т.е. ты можешь вот этот каталог зеркалить на такое-то количество устройств, так как оно очень важно. А вот это, нахрен не нужное - только в одном экземпляре хранить И оно таки работает. Ох уж эта экспертиза опеннета, безжалостная ты с-ка....
	Ответить | Правка | Наверх | Cообщить модератору

	188. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 18:32
	> Да, так то явно когда запиливали > Для надёжности, наличие журнала значительно уменьшает вероятность повреждения ФС при внезапном > отвале накопителя. Я это даже комментировать не стану. Просто оставлю эти две строчки для тех кто в курсе - когда запиливали, что на самом деле запилили, и когда все же подперли еще одним костыликом. > А если у меня дисковая полка с сотней дисков? А если у бабушки член? У тебя только г-няные флэшки портящие данные. По одной в каждом аналогов не имеющем наколенном устройстве. Ни одной дисковой полки ты не видел и не увидишь. (в полке, если что, редко бывает больше 24 spinning rust дисков, и то такие любят далеко не везде. Потому что весит такое чудовище 50 кило, со всеми вытекающими. Что делают, когда данные не помещаются в полку - ты узнаешь вероятно в следующей жизни, когда вылезешь за пределы своего пузырька)
	Ответить | Правка | Наверх | Cообщить модератору

	197. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 09-Фев-24, 10:18
	>в полке, если что, редко бывает больше 24 spinning rust дисков, и то такие любят далеко не везде. То есть больших решений ты не видел. WD Ultrastar 102 отсека (дешманское решение, правда, я его не люблю). И это не предел, есть полочки и побольше. То, что ты с этим не работал - это твои проблемы. Особенно "про их не везде любят". Есть места, где альтернатив тупо нет. 24 диска это даже не энтерпрайз толком, это херня, которая смысла, чаще всего, не имеет. >Что делают, когда данные не помещаются в полку Докупают еще полку. Ты даже тут умудряешься чушь нести.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 09-Фев-24, 11:21
	> То есть больших решений ты не видел. WD Ultrastar 102 отсека (дешманское > решение, правда, я его не люблю). И это не предел, есть > полочки и побольше. То, что ты с этим не работал - > это твои проблемы. Особенно "про их не везде любят". Есть места, > где альтернатив тупо нет. 24 диска это даже не энтерпрайз толком, > это херня, которая смысла, чаще всего, не имеет. >>Что делают, когда данные не помещаются в полку > Докупают еще полку. Ты даже тут умудряешься чушь нести. Черт, это прикол. На "энтерпрайзного" поха нашелся гораздо более забористый - и намного менее ушибленный энтерпрайзник. Куда более трезво смотрящий на некоторые вещи. И явно не застрявший в развитии в 2005 году как некоторые.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 09-Фев-24, 11:54
	> Черт, это прикол. На "энтерпрайзного" поха нашелся гораздо более забористый - и > намного менее ушибленный энтерпрайзник. Куда более трезво смотрящий на некоторые вещи. точно-точно. wd ultrastar на сотню дисков - трезво. Ок.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 10-Фев-24, 13:25
	>> Черт, это прикол. На "энтерпрайзного" поха нашелся гораздо более забористый - и >> намного менее ушибленный энтерпрайзник. Куда более трезво смотрящий на некоторые вещи. > точно-точно. wd ultrastar на сотню дисков - трезво. Ок. Ну, оно - существует. Он про него - знает. И при попытке взятия на понт - привел пример примерно того что ты хотел, с аргументом что так можно было. По моему нормально, не? Ну и если товар выпускают - на него клиент находится. Логично же.
	Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

	214. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (3), 09-Фев-24, 18:31
	> И явно не застрявший в развитии в 2005 году как некоторые. Особенно радует, что дисковые полки не любят за вес под 50 кило. У нас стойки по полтонны в среднем... Там плюс-минус полста килограмм - фигня полная. Это он еще нормальных упсов по сотне килограмм весом не видел.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 10-Фев-24, 01:24
	>> И явно не застрявший в развитии в 2005 году как некоторые. "явно не отставшего в развитии" походу в DC водят на экскурсии раз в году. >  Особенно радует, что дисковые полки не любят за вес под 50 > кило. У нас стойки по полтонны в среднем... Там плюс-минус полста > килограмм - фигня полная. Это он еще нормальных упсов по сотне да, да, полная. Пока тебе не понадобится ее выковырять потому что "саппорт что-то не уверен, но по-моему ошибки связаны с тем что у тебя навернулся backplane" (ну и модули контролеров не то чтоб совсем уж никак нельзя достать без полного демонтажа, но погеморроиться придется) И это - обычная "2005" (нет) полочка столько весит, достаточно небольшого объема, а не поделка от wd на сто дисков (там еще очень занимательно эти диски заменять, но особо одаренные не ищут легкой жизни) Ну и конечно же поверх всего этого у тебя будет единственная фс. Прям топ инженерное решение. Главное самому рядом не пробегать. > килограмм весом не видел. ну где уж мне. Только вот (нормальные люди, а не местные особо одаренные) используют нормальные упсы. Которые сами себе стойка и выковыривать оттуда надо только отдельные батарейки, что вполне доступно без подъемного крана.
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	220. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 10-Фев-24, 13:39
	> "явно не отставшего в развитии" походу в DC водят на экскурсии раз в году. Для меня больше похоже на то что зная похонаха - он там себе возомнил что его кейс единственно правилный, и вообще, все остальное - ересь, и либо невозможно, либо если вдруг - должно умереть, и желательно еще вчера. В общем похоже на обычный синдром утенка. Во всяком случае хамство и самолюбование - хреновые аргументы с технарями в чатике. > Ну и конечно же поверх всего этого у тебя будет единственная > фс. Прям топ инженерное решение. Главное самому рядом не пробегать. А тот Аноним(3) разве пытался тебя захантить ему это все майнтайнить? Нет? Ну тогда в чем проблемы? Если он и его контора разгребают - значит им норм. Почему ты решил что твой кейс единствнено верный и возможный на весь глобус - кто б тебя знает.
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

	224. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 10-Фев-24, 17:29
	> самолюбование - хреновые аргументы с технарями в чатике. ну вот и передай это тому "технарю", который рассказывает что у меня дешманское чтототам а вот у него-то огого - и попутно придумывает, чего я там видел, а чего не видел. (а на деле вытащил из подвала амазона вдшную помойку и гордится виденым через плечо "zfs на сто дисков") >> фс. Прям топ инженерное решение. Главное самому рядом не пробегать. > А тот Аноним(3) разве пытался тебя захантить типичная подмена понятий. Я про инженерное решение (антиинженерное) - ты опять переводишь на "да мой (неважно, того-анонима, уровень потребления горааааздо круче твоего)" > Если он и его контора разгребают - значит им норм. Он - фантазирует. Про то как пятипетабайтные single-fs стораджи бороздят еще недописанные файловые системы. Чего там его контора разгребает - похоже видел через плечи ответственных сотрудников. Ну и энтерпрайзом тут (с этой-то wd наперевес, и с упсами "по сто кило" которых я точно "не видел" и не догадываюсь даже, где и с какого горя появляются) даже и не пахнет. Подвальными импортозаместителями скорее вон разит. А если тебе ентерпрайс интересен и прикинуть его реальные запросы - как инженеру, а не про уровень потребления - то про наши мне еще пять лет нельзя, но вон аж целый тиньков набрал мусора на целых два петабайта, это открытый источник (наверное уже четыре, они быстро росли, но тем не менее - это одни из самых крупных у нас энтер-прайс коллекционеров чего не надобы). Ну разумеется во-первых это у них бэкап, во-вторых, разумеется, то что его видно как fs не означает что все петабайты сложены кучкой в единственную полку. (Само инженерное решение, тоже, прям скажем, аховое, но ту единственную задачу для которой собрали - решает, а лучше не факт что получилось бы.)
	Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

	226. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 10-Фев-24, 22:48
	> дешманское чтототам а вот у него-то огого - и попутно придумывает, > чего я там видел, а чего не видел. Ну ты вещал что так не бывает, а он пример "не бывающего" подогнал. По моему чистая техническая победа в дискуссии, и позорная неспособность признать это. > (а на деле вытащил из подвала амазона вдшную помойку и гордится виденым > через плечо "zfs на сто дисков") В любом случае он явно видел сетап о котором ты выдал что так не бывает. Теория должна согласовываться с наблюдаемыми фактами. Иначе это х-вая теория, и ниипет. > типичная подмена понятий. Я про инженерное решение (антиинженерное) - ты опять переводишь > на "да мой (неважно, того-анонима, уровень потребления горааааздо круче твоего)" Ну ты требовал пример, он тебе его дал. Фигли еще надо? Я то с более технической стороны, глядя на дизайн сабжа, могу выразить некоторый спектицизм например на тему менеджмент операций VS отсутствие backrefs пока кент хрустом всяким развлекается вместо решения ряда проблем дизайна. КМК попытка отменеджить что-то такого размера без backrefs будет довольно интересным, но не факт что позитивным опытом. >> Если он и его контора разгребают - значит им норм. > Он - фантазирует. Про то как пятипетабайтные single-fs стораджи бороздят еще > недописанные файловые системы. Вероятно он прикидывает как энный дизайн впишется в энную задачу. Так то это нормальный способ решения инженерных задач - представить себе процесс, и как это будет работать. И почему - так. Другое дело что можно угадать, а можно и нет. И это очень зависит от уровня того кто это практикует. > Чего там его контора разгребает - похоже видел через плечи ответственных сотрудников. Но ты вообще сказал что так не бывает 🤦‍ > где и с какого горя появляются) даже и не пахнет. Подвальными > импортозаместителями скорее вон разит. Да это уже его проблемы кто он там. Решать какие технологии где используются и obsolete, good/bad/whatever и проч не твоя прерогатива как таковая - и остальные могут иметь свои мнения по своим причинам на этот счет. Насколько я вижу, твое мнение вообще здорово расходится с мнением ALL насчет технологий и как надо. Это может и не всегда плохо, но твои слезные рассказы о том как ты прострелил пятки и как у тебя все не работает - вызывают идеи что это подвалил хороший пример "как делать не надо" на чужих ошибках. Если кто ноет - значит он выбрал х-вый путь, лучше попробовать иные подходы и варианты. > еще пять лет нельзя, но вон аж целый тиньков набрал мусора > на целых два петабайта, это открытый источник (наверное уже четыре, они > быстро росли, но тем не менее - это одни из самых > крупных у нас энтер-прайс коллекционеров чего не надобы). Ну я вообще не фанат больших централизованых монстров ибо большому кораблю - большая торпеда, в конце концов, а если кто хочет это узнать сложным способом - ну, окей. И все же в контексте сабжа и не только интересно какие инсталляции бывают и почему - такие. > (Само инженерное решение, тоже, прям скажем, аховое, но ту единственную задачу > для которой собрали - решает, а лучше не факт что получилось бы.) Да я б не стал от тинькова ждать супер-скилов, хайповые слишком, врядли у них серьезные core wranglers и приличные архитекты есть. Тем вооон те предложат в i++ раз больше, и без совкопроблем локации.
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	229. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 11-Фев-24, 19:57
	>> дешманское чтототам а вот у него-то огого - и попутно придумывает, >> чего я там видел, а чего не видел. > Ну ты вещал что так не бывает, а он пример "не бывающего" ты еще и читать не умеешь? Покажи мою цитату с "не бывает"? > В любом случае он явно видел сетап о котором ты выдал что на амазоне ты тоже можешь (наверное, давно не проверял) поглядеть. Оно любимо, в определенных кругах, но не энтерпрайзами. > Ну ты требовал пример, он тебе его дал. Фигли еще надо? я никаких примеров не требовал. > Вероятно он прикидывает как энный дизайн впишется в энную задачу. Так то Которой правда пока нет, но прикидывает. С чего весь тред и начался. Нет ни задачи, ни софта, ни адекватного железа и нескоро будет. К тому моменту вот например гибридные полки - очень вряд ли сохранятся, потому что их уже и сейчас разлюбили, задача решается в другом месте и на другом уровне. А типовой ентер-прайс хочет "all flash", потому что надевляпали тормозного г-на. Но ему не надо там петабайтов в одном флаконе, нету у него столько. > Ну я вообще не фанат больших централизованых монстров ибо большому кораблю - опять слился. Ну что ж такое? Скажи уж честно - твой предел - флэшечки в пердолинках. Вот про них я был бы готов тебя послушать, например - где ты купил те что неправильные данные без ошибок отдают и как их опознать (но ты конечно же не расскажешь). Остальное - вне компетенций и вне поля зрения как такового - просто потому что самоучку без мотора не позовут туда где оно бывает. (А позовут - напорешься на ту самую wd и "стакилограммовый упс" - беги оттуда!) Поэтому просто неинтересно обсуждать. И с тем чуваком тоже вряд ли интересно - я бы позадавал вопросов про чюду-юду-с zfs, но ведь опять фигня окажется.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	233. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 12-Фев-24, 10:53
	Повторяешься. Даже не интересно. Ты сам то вообще что-то кроме флэшечек видел? После твоих последних пассажей - дюже сомневаюсь.
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	210. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 09-Фев-24, 11:53
	> Есть места, где альтернатив тупо нет. да, другим способом сразу потерять очень много данных вероятно только при помощи динамита получится. >>Что делают, когда данные не помещаются в полку > Докупают еще полку. о, точно! Безумству храбрых... впрочем они не храбрые а просто глупые.
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	204. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 09-Фев-24, 11:26
	> Вау. Это прям эксперт уровня "бог". Для надежности, дорогой ты наш. Я предпочитаю писать это как эксперт уровня бох^W пох (нах и пох это или 1 тип или 2 похожих по менталитету). Так сразу уровень очевиден - даже ежику становится понятно что ща накормят последними know-how из 2005 года! А если сильно повезет - может и 2010 "аж" =).
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	112. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 12:20
	Про 0 ты брешешь, кстати. Лучше говори, что тебе везло и ты раздолбай так и не заметил ничего особо деструктивного. В это можно поверить, в противном случае, все видят, что ты никогда не пользовался этой фс.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	118. Скрыто модератором	+/–
	Сообщение от нах. (?), 08-Фев-24, 13:37
	> Про 0 ты брешешь, кстати. Лучше говори, что тебе везло и ты > раздолбай так и не заметил ничего особо деструктивного. В это можно Если никто ни разу за пятнадцать лет не заметил - значит ничего особо деструктивного там и не было. > поверить, в противном случае, все видят, что ты никогда не пользовался > этой фс. Ну конечно, куда мне до очередного эксперта опеннета. Малыш, ты не понимаешь что СЕБЯ со своим "видением" выставляешь полным дypaчком?
	Ответить | Правка | Наверх | Cообщить модератору

	216. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 10-Фев-24, 00:05
	> прав и f2fs ещё веселее. Но кто её массово в проде > использует? А что не так с f2fs ? Интересуюсь,подумывал даже одно время переходить на неё,огорчило отсутствие контрольной суммы для данных.Смутило отсутствие народа её использующие-хотя для обычных жестких дефрагментатор запилили,загрузка с нее теперь возможна.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	223. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 10-Фев-24, 15:06
	Народ как раз во всю использует f2fs - в смартфонах. Другое дело, что буквы ФС народу обычно не понятны.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 10-Фев-24, 20:07
	> Народ как раз во всю использует f2fs - в смартфонах. Другое дело, > что буквы ФС народу обычно не понятны. В смартах ее юзают - на некритичных разделах, и там питание всегда подперто батарейкой, а при ее посадке шадтаун - корректный. А вот если условия от идеала вдруг отличаются - у меня при powerloss тестах f2fs очень быстро разлетелся до состояния когда с одной стороны он не маунтится, а с другой fsck не может это починить ибо не видит проблем. В моем словаре это попадает под "что не так", очевидно. Хотя настоящая проблема - что один корейский Jeon (кодер из самсуня) на штуки 4 здоровых проекта надрывался, будучи явно перегруженным. Ну качество проектов - таки - хромает от такого.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 11-Фев-24, 00:07
	>В моем словаре это попадает под "что не так", очевидно. Хм, а апологеты COW (btrfs)  кричат что всё ......и провакация, получается не всегда COW спасает (для незнающих, в f2fs  тоже внедрили COW).Хотя у этой фс метаданные подперты контрольной суммой.И с самого начала продуманная  btree чуть не дотягивает до v2 у btrfs :-) , но это понятно что она рассчитывалась на флэшки,а там параллельные потоки стандартная ситуация.Понятненько, fsck значит ещё не доделали.И с контрольной суммой для данных пока грустно, хотя для старой ext4 пишут внешний костыль.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 12-Фев-24, 09:20
	> Народ как раз во всю использует f2fs - в смартфонах. вон два смартфона еще живы - ни в одном нету. Сплошная ext4, как жы так?! f2fs - поделка самсуня, решавшая (давние и уже не нуждающиеся в таком решении) проблемы - самсуня и его тормозного флэша. Причем для эффективной работы требующая специфических знаний о его внутренней структуре. Обрати внимание - гугль побрезговал.
	Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

	232. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 12-Фев-24, 10:21
	>f2fs - поделка самсуня Уже давно не подделка.Очень много запилили,в том числе и для использования на обычных дисках- другое дело качество кода,не все хорошо как хочется.Добавили COW,сжатие,дефрагментацию.Допилили модуль для grub ,сделав эту фс загрузочной.Я протестировал ее для внешних дискав для всяких файлов, неплохо,совсем неплохо по скорости, особенно для пустого диска.С мелкими файлами до какого-то момента быстрее btrfs работает,потом скорости выравниваются.Понимаю что риск потери данных выше, т.к агрессивный кэш в ОЗУ (отложенная запись) и нет crc для данных.Я ее глубоко не тестировал,( но за 2 года использования нечего не вылезло) но по крайне мере как UDF не разваливается, вот уж точно фс на которую даже  дышать страшно, при полном отсутствии fcsk.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 12-Фев-24, 12:42
	> Допилили модуль для grub ,сделав эту фс загрузочной. Вроде бы так и нет поддержки ФС с включенным extra_attr https://github.com/search?q=repo%3Aolafhering%2Fgr...
	Ответить | Правка | Наверх | Cообщить модератору

	237. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 12-Фев-24, 13:32
	>Вроде бы так и нет поддержки ФС с включенным extra_attr Хм ,вики Начиная с GRUB 2.04 (5 Июля 2019) можно использовать раздел с F2FS как загрузочный. https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs... https://opennet.ru/51038-grub ++нужно какая то версия ядра , если включено сжатие,были проблемы
	Ответить | Правка | Наверх | Cообщить модератору

	238. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 12-Фев-24, 14:15
	Вот другая "вики" https://wiki.archlinux.org/title/F2FS#GRUB_support While GRUB supports F2FS since version 2.0.4, it cannot correctly read its boot files from an F2FS partition that was created with the extra_attr flag enabled (for more details, see GRUB#Unsupported file systems). К ней у меня больше доверия, поскольку перепроверял и было так. С тех пор прошло некоторое время, но в коммитах доработки не вижу.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 12-Фев-24, 14:45
	> К ней у меня больше доверия, поскольку перепроверял и было так. С > тех пор прошло некоторое время, но в коммитах доработки не вижу. Ну и  кто мешает grub и ядро с инитр в не сжатом и шифрованном каталоге разместить ?
	Ответить | Правка | Наверх | Cообщить модератору

	242. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 13-Фев-24, 07:50
	>> К ней у меня больше доверия, поскольку перепроверял и было так. С >> тех пор прошло некоторое время, но в коммитах доработки не вижу. > Ну и  кто мешает grub и ядро с инитр в не > сжатом и шифрованном каталоге разместить ? Тот, кто мешает помнить тезис, который я поставил под сомнение: "допилили модуль для grub ,сделав эту фс загрузочной". Пишу, кстати, с f2fs созданной с extra_attr. GRUB просто выкинут за ненадобностью.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 12-Фев-24, 14:54
	Стоп, стоп - а ЗАЧЕМ они всей этой фигней вот заняты? Какие-такие проблемы оно решает которые не решаются банальной ext4 ? Изначальный поинт был именно в том что они лучше знают (свои!) флэшки и их особенности - и там это имело какой-то смысл... если ты сотрудник самсунг. Потому что про флэшку из ларька ты знаешь ровно ничего. А еще одна фс общего назначения к десятку имеющихся и при этом с кучей странностей - вот накой? Ну и единственный гребец на той галере, точнее, 1шашнадцатая потому что ему велено веслать еще вон ту флотилию тоже в одно жало...
	Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

	241. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от maximnik0 (?), 12-Фев-24, 21:53
	> А еще одна фс общего назначения к десятку имеющихся и при этом > с кучей странностей - вот накой? Ну все таки она попроще чем btrfs. Нет LVM и RAID - и на поддержку этих свойств они и не замахиваються.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от n00by (ok), 12-Фев-24, 12:36
	>> Народ как раз во всю использует f2fs - в смартфонах. > вон два смартфона еще живы - ни в одном нету. Сплошная ext4, > как жы так?! Луддитный раритетчик отстал от народа. Небось ещё и предпочитает замшелые напитки трендовым технологиям ускорения выдержки.
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	24. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 16:33
	> Оно метит в гильдию ибийц ZFS? Оно метит в nextgen nextgen'а. И по своему таковым является. Идея объединить SSD и HDD в единый стораж, где на фронт скорость SSD а на бэк емкость HDD - не так уж и плохо придумано. В каком-то роде это гибрид low-overhead респина идей btrfs с идеями кеша bcache, на основе технологий оттуда. Местами заметно отличается от btrfs по деталям некоторых решений - однако общая семантика операций и управление весьма похожи. Ибо это было лучшее по управлению на момент создания этой штуки.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	46. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Mr.Who (?), 07-Фев-24, 18:27
	Зачем объединять SSD и HDD в единый сторадж? В чём смысл данного подхода?
	Ответить | Правка | Наверх | Cообщить модератору

	51. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 07-Фев-24, 18:47
	> Зачем объединять SSD и HDD в единый сторадж? В чём смысл данного подхода? Если записи эпизодические, то... 1) При записи, ее поймает супербыстрый SSD и она завершится в момент. 2) А потом в фоне файлуха перебазирует это на HDD, с CoW семантикой это даже относительно безопасное действо. 3) Можно также и кеш "горячих" данных на SSD сделать. Поэтому в идеале получается емкость харда, которая при записи или чтении часто используемого будет ощущаться почти как SSD. Что как бы довольно крутая идея сама по себе. Народ юзал bcache (не FS!) и раньше, но это довольно дурно взаимодействует с ФС не будучи в курсе требований избыточности и проблем стоража. Так что когда SSD протирается - может получиться не очень. А тут вот это интегрировано с менеджментом избыточности и в ФС с избыточностью оно смогет довольно осмысленно парировать все это по задумке. Собственно интеграция фронтэнда и кеша в многоуровневый иерархический стораж - ну так то довольно круто придумано. И вот именно FS-aware оно имхо имеет шансы быть заметно менее кривое чем потуги это целиком на блочном уровне делать. На блочном часто вело к разлету ФС вдрызг при кончине SSD под кешом.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (3), 07-Фев-24, 19:57
	Ну вот у меня меееедленный SMR и шустренький SSD. И как-то вот объединил. И вот как-то даже всё работает как на SSD, за исключением данных, к которым редко обращаюсь, но тут такое... Чтение в основном линейное, поэтому и это не такая уж большая потеря в скорости. Прикинь, да?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	68. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от RocketShark (?), 07-Фев-24, 23:28
	У меня всегда система на ссд, данные - на hdd рейдах. Не понимаю ваших проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от n00by (ok), 08-Фев-24, 08:15
	У некоторых данные - это не видео с котиками, а исходники, с которыми приходится что-то делать не отвлекаясь на питиё кофея.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 08:37
	Ну и не понимаейте. У меня вот система на одном SSD, а хомяк собран из вот такого бутерброда. Это, знаете ли, чтобы когда вот я работаю с данными - они грузились быстро. А когда они мне надоедают (ну перестал я в танки играть - нах их в кэше держать?) - оседают на мееедленный носитель, а на SSD переезжает что-то более нужно. Вот, например, давеча проектик собирал, который зависит от дисковых операций. И как-то мне норм, а вот на hdd рейдах да в ноуте... Это вы фантастики перечитали.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

54. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от Аноним (54), 07-Фев-24, 19:42
С чего такой вой в комментах? "Первая попытка удаления закончится ошибкой" - и чего тут такого, что ужас-ужас-ужас? Бедный сисадмин надорвётся до выхода исправления удалять эти несуществующие сабы со второй попытки?
Ответить | Правка | Наверх | Cообщить модератору

	67. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Аноним (3), 07-Фев-24, 23:15
	А со второй попытки оно повиснет. Тут вопрос в том, что кейс реально кривой, т.е. для его воспроизведения надо впринципе уже накосячить. Причем, предположительно, автоматизированно. Т.е. да, баг, но специфичный.
	Ответить | Правка | Наверх | Cообщить модератору

75. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+3 +/–
Сообщение от Аноним (75), 08-Фев-24, 01:02
А Шишкин, между прочим, предупреждал...
Ответить | Правка | Наверх | Cообщить модератору

	82. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от DEF (?), 08-Фев-24, 02:57
	Предупреждал, что не сможет допилить Reiser5 и забросит её в 2020 году.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (-), 08-Фев-24, 12:41
	> А Шишкин, между прочим, предупреждал... Ну вы можете пользоваться файлухами от Шишкина если они для вас лучше работают, вам же никто не запрещает :)
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	172. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (100), 08-Фев-24, 16:52
	А кто-нибудь видел этого Шишкина в лицо? А то я сколько ни гуглил, кроме его интервью ничего не могу найти ))
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

78. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–2 +/–
Сообщение от Аноним (78), 08-Фев-24, 01:15
После ядра 3.16 практически невозможно добиться нулевого (в простое) I/O дисковой подсистемы даже на Ext2, скатился и сдулся ваш Линукс.
Ответить | Правка | Наверх | Cообщить модератору

	93. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (3), 08-Фев-24, 08:39
	Да как я это делаю? О_О Магия, наверное. Единственную сложность из себя представляют журналы, которые иногда пишутся не к месту и слишком подробно. Но это ж решается.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от Скатилсо (?), 08-Фев-24, 12:10
	Какие ещё журналы в Ext2? Нет, скатился, да и IBM нафиг не нужен линукс на десктопе.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (3), 08-Фев-24, 15:00
	Журналы программ. Прикинь, это все же журналы. Даже служба, которая их пишет называется journald.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от edo (ok), 12-Фев-24, 10:18
	Какое отношение версия ядра имеет к дисковому io? Оно по своей инициативе не читает и не пишет (исключения можно найти, но это именно исключения)
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

87. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от Аноним (87), 08-Фев-24, 07:29
Нет бы на расте писать, супербезопасный язык, избавляет от ошибок с памятью
Ответить | Правка | Наверх | Cообщить модератору

	94. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 08:40
	Вот ты вот щас зря стебаешься, ибо bcachefs-tools частично на расте, а в ядро 6.9 полетит уже и в ядро раст в bcachefs. Так что можешь засунуть в некоторое место себе свой сарказм :3
	Ответить | Правка | Наверх | Cообщить модератору

	95. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (95), 08-Фев-24, 09:23
	отличные новости, в расте нет проблем с блокировками, многопоточностью и утечками памяти. А для упрощения сопровождения другими мантейнерами есть магические операторы unsafe.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 13:45
	> в ядро 6.9 полетит уже и в ядро раст в bcachefs. А источник этих данных - какой? Пруфлинк?
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	145. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 15:05
	https://lore.kernel.org/linux-bcachefs/20240207055558.611606... Нормальный пруф про ядро? Про bcachefs-tools оно собирается с растом, если кто не верит - идите и собирайте руками.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (108), 08-Фев-24, 15:51
	Это какой-то позор
	Ответить | Правка | Наверх | Cообщить модератору

	192. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 08-Фев-24, 20:54
	> https://lore.kernel.org/linux-bcachefs/20240207055558.611606... > Нормальный пруф про ядро? Нормальный, котируется! Правда, для меня сие означает что я останусь на btrfs и - пока вынесу сие из билдконфигов, если хруст будет именно в обязаловку. Как минимум до момента появления нормального gccrs. Более того - дискуссия там весьма забавная. Но вообще эксперимент на мой вкус любопытный. Если вон то прокатит, это будет первое практичное применение хруста которое я видел. Я не враждебен новым технологиям "из принципа". Но иметь дело с LLVMным тулчейном - не собираюсь, вот хоть там как. Более того - если gccrs допилят, я допускаю идею подучить хруст, посмотреть что получится. Почему нет? Просто - не сейчас. Сейчас это слишком гиморно и слишком "too far off the track". > Про bcachefs-tools оно собирается с растом, если кто > не верит - идите и собирайте руками. Вообще-то я это и сделал. И там был режим сборки без хруста. Если это отломали - ну окей, я не буду чекаутить и билдить новую версию этого. Спасибо что предупредили. Это не мешает создавать ФСы :)
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	200. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 09-Фев-24, 10:23
	Там хруст не в обязаловку. Но ты в функционале можешь потерять (ЕМНИП, там был какой-то момент, я его не помню, читал что-то про дебьян, который собрал это без хруста). Пруфов, естесно, не дам, ибо сам только где-то читал, да еще и где - не помню.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 09-Фев-24, 11:31
	> Там хруст не в обязаловку. Но ты в функционале можешь потерять (ЕМНИП, > там был какой-то момент, я его не помню, читал что-то про > дебьян, который собрал это без хруста). Пруфов, естесно, не дам, ибо > сам только где-то читал, да еще и где - не помню. Ну, лично я на данный момент не собираюсь с хрустом в виде LLVM тулчейна дело иметь. К тому же это кроме всего прочего вынесет поддержку 32 битных ARM (кернель не поддерживает хруст под 32-бит ARM) а без этого мне оно сильно менее интересно для моих кейсов, соответственно. И как бы неработа на 32 бит армах будет идти жестко вразрез с изначальными декларациями намерений General Purpose файлух, годных для low mem, компактных и проч. Если к этому придет, я буду вынужден отметить что слова и дела здорово разошлись.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 09-Фев-24, 11:43
	Ну таки неработа на 32 бит армах - это частность. General purpose не обязывает на этом работать. Но да, область применения в embedded сократит, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (-), 10-Фев-24, 13:55
	> Ну таки неработа на 32 бит армах - это частность. General purpose > не обязывает на этом работать. Но да, область применения в embedded > сократит, конечно. Ну как бы со своей стороны я при таком раскладе посчитаю что кой-кто был не совсем честен со мной относительно декларации намерений. С экспериментальной штуки спроса немного, конечно, но зачем тогда на сайте на видном месте обещать - вон то? И тут вдруг - тыдыщ, 64-bit req'd по сути? O_O
	Ответить | Правка | Наверх | Cообщить модератору

117. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
Сообщение от Аноним (117), 08-Фев-24, 13:24
Когда-то давным давно для себя определил, что ext3 подходит примерно для любых задач и в любой непонятной ситуации надо брать ее и с вероятностью 99% можно будет ничего не менять в дальнейшем. С тех пор ничего не изменилось (кроме появления ext4).
Ответить | Правка | Наверх | Cообщить модератору

	146. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–2 +/–
	Сообщение от Аноним (3), 08-Фев-24, 15:06
	Хорошо. У нас блочный сторадж на 5 петабайт на хардах. И 500 терабайт на SSD. И все это надо разметить в одну ФС. И получить максимальную производительность. Bcachefs - единственная на сегодняшний день, кто решает эту задачу.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 15:26
	> Хорошо. У нас блочный сторадж на 5 петабайт на хардах. И 500 > терабайт на SSD. И все это надо разметить в одну ФС. > И получить максимальную производительность. Bcachefs - единственная на сегодняшний день, то есть ты потратил денег на петабайтный сторадж возможный только на fs, которую еще не написали? (про сам факт петабайтного стораджа на ЕДИНСТВЕННОМ хосте - уже не будем даже) > кто решает эту задачу. то есть по факту никого. Б-же упаси от поделок местных экспертов.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
	Сообщение от Аноним (3), 08-Фев-24, 18:20
	ТО есть ты про дисковые полки, блин, не слышал? И даже про дисковые хранилища, в которых это может стать применимым не подумал? Ты сразу решил, что у меня такой сторадж на одном хосте и я потратил на него деньги? Да ты прям Ванга, неудавшаяся.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 08-Фев-24, 18:41
	> ТО есть ты про дисковые полки, блин, не слышал? И даже про когда ты увидишь дисковую полку не на картинке - напиши сюда. > сразу решил, что у меня такой сторадж на одном хосте и > я потратил на него деньги? Да ты прям Ванга, неудавшаяся. да нет, я как раз прекрасно понимаю что ты фантазируешь. Твой предел стораджа - флэшечка с багом. Дисковые полки с hybrid storage существуют давным-давно (и уже вымирающий вид), но пока как-то без чудо-фс обходятся (если что - у нетаппы там - вариация на тему zfs). А когда ее допишут - наверное уже вымрут окончательно. Уже лет десять немодно и лет пять как совсем уж неприлично. Но петабайтные хранилища не собирают подобным образом. Ну разьве что очень богатые и глупые, нанявшие очень одаренных. Я в тебя верю, вы со своим клиентом когда-нибудь найдете друг-друга.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 09-Фев-24, 10:30
	>да нет, я как раз прекрасно понимаю что ты фантазируешь Да нет, фантазии тут только твои. Дисковая полочка на 100 дисков крутится, но не у меня, а у моего работодателя. И там, простите, ZFS раскатана. А у меня таких стораджей нету, и к работодателю я сабж этот не понесу, по понятным причинам. >и уже вымирающий вид Мляяя, ну экспертность опять уровня "бог". Даже комментирвоать не хочу. Есть задачи, и есть их решения. >Но петабайтные хранилища не собирают подобным образом. Ну разьве что очень богатые и глупые, нанявшие очень одаренных. Петабайтные хранилища не собирают сегодня. А когда-то не собирали и гигабайтные таким образом. Ты емкость хардов давно видел? Таким образом сегодня собирают до 500 Тб. Но тебе, видимо, это неведомо. >если что - у нетаппы там - вариация на тему zfs Аааа. Ну всё понятно. HPE и иже с этим ты в глаза не видел, только дешмань с помойки, и то, похоже, только по слухам.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от нах. (?), 09-Фев-24, 11:30
	> Да нет, фантазии тут только твои. Дисковая полочка на 100 дисков крутится, но не у меня, а у > моего работодателя. ну понятно. Тебя на экскурсию туда хоть водили, или так - по рассказам коллег ориентируешься? > И там, простите, ZFS раскатана. Скудоумие и отвага? Нет, скудоумие и скудоумие! > Петабайтные хранилища не собирают сегодня. чего вдруг? Собирают, вполне себе. Но они не выглядят как полка на 10000 дисков. И дело тут не в емкости хардов. Она скорее минус чем плюс.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 09-Фев-24, 11:41
	Весь коммент похож на бред душевнобольного. Выдернул слова из контекста, переиначил... И одно из двух: либо балабол, либо крышей поехал (ставлю на первое).
	Ответить | Правка | Наверх | Cообщить модератору

	153. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (156), 08-Фев-24, 15:38
	> Хорошо. У нас блочный сторадж на 5 петабайт на хардах. И 500 > терабайт на SSD. И все это надо разметить в одну ФС. Жесткий вы тип, EXT3 столько вообще IIRC не умеет :) > И получить максимальную производительность. Bcachefs - единственная на > сегодняшний день, кто решает эту задачу. А что, он реально на таком монстрике пашет? Было бы очень круто узнать детали прода если это возможно. Потому что если это оно - возможно это рекордное применение на данный момент.
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	177. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (36), 08-Фев-24, 17:22
	Выглядит, как архив фоточек, скорее всего им и является. Да мало ли применений придумать можно, какая вообще разница? 5 пб это 160 жёстких дисков или 51 100тб ссд (но эти дороговаты были с предлагаемой производительностью).
	Ответить | Правка | Наверх | Cообщить модератору

	186. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 18:21
	Да не пашет она на таком монстрике. Но она занимается решением такой задачи, запашет. Потом, как-нибудь. У меня такого стораджа нету, естесно, я просто задачу предложил. У меня сейчас 50Тб / 500 Гб - и таки пашет ).
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	191. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от User (??), 08-Фев-24, 18:50
	Ну, т.е. Сторажки нет, файлухи под неё нет - думаю и задачи n пб в одной файлухе тоже нет - шах-и-мат, неудачники!
	Ответить | Правка | Наверх | Cообщить модератору

	199. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 09-Фев-24, 10:21
	Ну т.е. задачу эта файлуха решает теоретически, по спецификациям. Т.е. файлуха есть, но по понятным причинам в прод ее никто не выпустил. Ну и задача то есть такая, у тебя, может и нету. У меня оно крутится там, где ничего страшного не зафейлит пока ещё, и в прод она пойдет не раньше чем через два выпуска LTS ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от User (??), 09-Фев-24, 12:00
	> Ну т.е. задачу эта файлуха решает теоретически, по спецификациям. Т.е. файлуха есть, > но по понятным причинам в прод ее никто не выпустил. Ну > и задача то есть такая, у тебя, может и нету. У > меня оно крутится там, где ничего страшного не зафейлит пока ещё, > и в прод она пойдет не раньше чем через два выпуска > LTS ядра. А. Есть задача - но секретная, есть файлуха - но не рабочая, есть сторажка указанного объёма - но не у тебя. Ясно-понятно.
	Ответить | Правка | Наверх | Cообщить модератору

149. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	–1 +/–
Сообщение от Пряник (?), 08-Фев-24, 15:28
Либо Linux на каждый коммит вешает запуск всех известных статических анализаторов и проверку тестами, либо Linux переписываем на Rust.
Ответить | Правка | Наверх | Cообщить модератору

	159. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+2 +/–
	Сообщение от Аноним (108), 08-Фев-24, 15:53
	Вперед, переписывай
	Ответить | Правка | Наверх | Cообщить модератору

	171. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+1 +/–
	Сообщение от нах. (?), 08-Фев-24, 16:52
	> Вперед, переписывай да вон эти автыри аналогов не имеющих фс уже начинают. Кстати, никто не подскажет, чего им сразу-то не хрустелось, зачем эти промежуточные приседания требующие потом опять переписькивать уже работающее, тратя свою единственную жизнь и возмжно еще и внося новые баги?
	Ответить | Правка | Наверх | Cообщить модератору

	187. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от Аноним (3), 08-Фев-24, 18:27
	bcachefs разрабатывается 10+ лет. Ты, видимо, любишь рассуждать о том. о чем понятия не имеешь...
	Ответить | Правка | Наверх | Cообщить модератору

228. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
Сообщение от Олег (??), 11-Фев-24, 03:38
bcachefs уже научился работать с накопителями в которых начались бедблоки или отпадание накопителя на милисекунды? 5 лет назад SSD был который вышел по ресурсу и начал свое неадекватное поведение, и все данные ушли ....
Ответить | Правка | Наверх | Cообщить модератору

	234. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."	+/–
	Сообщение от edo (ok), 12-Фев-24, 10:57
	5 лет назад был bcachefs?
	Ответить | Правка | Наверх | Cообщить модератору

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

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