forum.opennet.ru - "Продвижение Bcachefs в состав ядра Linux и переписывание на Rust" (226)

"Продвижение Bcachefs в состав ядра Linux и переписывание на Rust"

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

"Продвижение Bcachefs в состав ядра Linux и переписывание на Rust"	+/–
Сообщение от opennews (?), 19-Июн-23, 11:06
Кент Оверстрит (Kent Overstreet), автор входящей в состав ядра Linux... Подробнее: https://www.opennet.me/opennews/art.shtml?num=59314
Ответить \| Правка \| Cообщить модератору

Оглавление

Скрыто модератором, DEF (?), 11:06 , 19-Июн-23, (1) –25

Скрыто модератором, Аноним (2), 11:09 , 19-Июн-23, (2) +8
Скрыто модератором, Аноним (3), 11:10 , 19-Июн-23, (3) +12

Скрыто модератором, Аноним (6), 11:23 , 19-Июн-23, (6)

Скрыто модератором, Анонин (?), 11:31 , 19-Июн-23, (13) +5

Скрыто модератором, Аноним (6), 12:09 , 19-Июн-23, (18)

Скрыто модератором, asdasd (?), 12:50 , 19-Июн-23, (30) +3

Скрыто модератором, Аноним (35), 13:22 , 19-Июн-23, (35) –1

Скрыто модератором, Аноним (77), 15:51 , 19-Июн-23, (77) +2

Скрыто модератором, torvn77 (ok), 00:30 , 21-Июн-23, (195)

Скрыто модератором, n00by (ok), 16:54 , 19-Июн-23, (81)

Скрыто модератором, DEF (?), 19:30 , 19-Июн-23, (99) –4

Скрыто модератором, Аноним (113), 23:55 , 19-Июн-23, (113)

Скрыто модератором, DEF (?), 02:02 , 20-Июн-23, (132)

Скрыто модератором, n00by (ok), 05:59 , 20-Июн-23, (140)
Скрыто модератором, Аноним (-), 18:13 , 20-Июн-23, (170)

Скрыто модератором, Аноним (126), 00:49 , 20-Июн-23, (126) +1

Скрыто модератором, DEF (?), 01:55 , 20-Июн-23, (129)

Скрыто модератором, Аноним (160), 13:14 , 20-Июн-23, (160)

Скрыто модератором, Чукча (?), 15:46 , 20-Июн-23, (162)
Скрыто модератором, Аноним (-), 18:59 , 20-Июн-23, (179)

Скрыто модератором, Аноним (8), 11:25 , 19-Июн-23, (8) +5

Скрыто модератором, Вы забыли заполнить поле Name (?), 14:46 , 19-Июн-23, (52)

Скрыто модератором, Аноним (94), 17:43 , 19-Июн-23, (94) +1

Скрыто модератором, Аноним (104), 21:32 , 19-Июн-23, (104)

Скрыто модератором, Аноним (112), 23:50 , 19-Июн-23, (112)

Скрыто модератором, Аноним (-), 23:21 , 19-Июн-23, (111) +2

Скрыто модератором, Аноним (94), 17:28 , 20-Июн-23, (168)

Скрыто модератором, Аноним (-), 18:30 , 20-Июн-23, (171)

Скрыто модератором, Аноним (94), 21:11 , 20-Июн-23, (191)

Скрыто модератором, Аноним (197), 01:36 , 21-Июн-23, (197)

Скрыто модератором, Аноним (94), 14:56 , 21-Июн-23, (222)

Скрыто модератором, Аноним (63), 15:20 , 19-Июн-23, (63)

Скрыто модератором, Аноним (118), 00:16 , 20-Июн-23, (118)

Скрыто модератором, Аноним (10), 11:28 , 19-Июн-23, (10) +3

Скрыто модератором, Аноним (15), 11:54 , 19-Июн-23, (15) +5

Скрыто модератором, Аноним (6), 12:07 , 19-Июн-23, (17) +1

Скрыто модератором, Аноним (15), 12:12 , 19-Июн-23, (21) +2

Скрыто модератором, Аноним (6), 15:44 , 19-Июн-23, (71)
Скрыто модератором, Аноним (158), 12:40 , 20-Июн-23, (158)

Скрыто модератором, Аноним (15), 13:08 , 20-Июн-23, (159)

Скрыто модератором, leap42 (ok), 12:46 , 19-Июн-23, (28) +2

Скрыто модератором, Аноним (15), 14:56 , 19-Июн-23, (59)
Скрыто модератором, Аноним (6), 15:46 , 19-Июн-23, (73)

Скрыто модератором, leap42 (ok), 05:33 , 20-Июн-23, (138) +1

Скрыто модератором, Аноним (102), 21:27 , 19-Июн-23, (102)

Скрыто модератором, leap42 (ok), 05:36 , 20-Июн-23, (139)

Скрыто модератором, Аноним (16), 12:07 , 19-Июн-23, (16)
Скрыто модератором, НяшМяш (ok), 12:22 , 19-Июн-23, (24)

Скрыто модератором, Аноним (114), 23:59 , 19-Июн-23, (114) +1

Скрыто модератором, Аноним (118), 12:29 , 19-Июн-23, (25) –1
Скрыто модератором, Alladin (?), 12:41 , 19-Июн-23, (26)

Скрыто модератором, Аноним (118), 00:18 , 20-Июн-23, (119)

Скрыто модератором, Аноним (33), 13:20 , 19-Июн-23, (33) +1

Скрыто модератором, Аноним (39), 13:48 , 19-Июн-23, (39) +2

Скрыто модератором, Витюшка (?), 14:04 , 19-Июн-23, (41) +1

Скрыто модератором, Аноним (33), 14:15 , 19-Июн-23, (42) –5

Скрыто модератором, Аноним (35), 15:33 , 19-Июн-23, (67)
Скрыто модератором, Аноним (-), 00:34 , 20-Июн-23, (124) +2

Скрыто модератором, Аноний (?), 11:27 , 20-Июн-23, (156) –1

Скрыто модератором, Аноним (174), 18:45 , 20-Июн-23, (174) –1

Скрыто модератором, Аноним (135), 03:41 , 20-Июн-23, (135) +2

Скрыто модератором, Аноний (?), 11:16 , 20-Июн-23, (154)

Скрыто модератором, Администратор (?), 06:46 , 20-Июн-23, (142)

Скрыто модератором, t (??), 11:18 , 20-Июн-23, (155) +1

Скрыто модератором, пох. (?), 15:58 , 20-Июн-23, (164)

Скрыто модератором, Аноним (-), 18:49 , 20-Июн-23, (176)

Скрыто модератором, maximnik0 (?), 12:10 , 19-Июн-23, (19) +2

Скрыто модератором, Аноним (174), 00:05 , 20-Июн-23, (116)

Скрыто модератором, maximnik0 (?), 01:38 , 20-Июн-23, (128) +1

Скрыто модератором, Аноним (-), 19:22 , 20-Июн-23, (183)

Скрыто модератором, maximnik0 (?), 21:45 , 20-Июн-23, (192)

Скрыто модератором, Аноним (-), 01:53 , 21-Июн-23, (198)

Скрыто модератором, maximnik0 (?), 02:59 , 21-Июн-23, (206)

Скрыто модератором, DEF (?), 01:57 , 20-Июн-23, (130) –1

Скрыто модератором, анон (?), 14:42 , 19-Июн-23, (46) +2

Скрыто модератором, DEF (?), 02:08 , 20-Июн-23, (134) +1

Скрыто модератором, Аноним (-), 18:27 , 19-Июн-23, (97)

Скрыто модератором, DEF (?), 01:59 , 20-Июн-23, (131)

Скрыто модератором, Аноним (-), 19:24 , 20-Июн-23, (184)

99 современных кодерков именно такие, Аноним (4), 11:13 , 19-Июн-23, (4) –1

ты понимаешь значение слова отлаживать , Аноним (8), 11:23 , 19-Июн-23, (7) +3

Поделись своим пониманием этого слова , YetAnotherOnanym (ok), 11:29 , 19-Июн-23, (12) +1

Вычищать из кода лажу , Random (??), 12:19 , 19-Июн-23, (23) +7

Отлаживать значит ложить на более далёком расстоянии чем сейчас, Самый Лучший Гусь (?), 12:15 , 19-Июн-23, (22) +5
Устранять несоответствие между тем, что программист хотел написать, и тем что он, Аноним (75), 15:51 , 19-Июн-23, (75) +4

И ни один язык не спасёт программиста от неправильно применённых алгоритмов Есл, Аноним (98), 18:28 , 19-Июн-23, (98)

А написали бы дебажить как в оригиналеи никакого лингвистического спора не был, Аноним_5 (?), 15:41 , 19-Июн-23, (69) +3

А нет никакого спора Зачем обезьянничать, когда есть свои слова , Neon (??), 18:41 , 20-Июн-23, (172) –1

На ютубе один лингвист высказал такое мнение неправильных слов нет и если debug, torvn77 (ok), 00:34 , 21-Июн-23, (196)

Железобетонная неоспоримая логика, конечно Давайте тогда фуск и фак добавим , Аноним (221), 13:31 , 21-Июн-23, (221)

Скрыто модератором, Аноним (-), 19:27 , 24-Июн-23, (237)

Скрыто модератором, n00by (ok), 17:02 , 19-Июн-23, (82) +2

Скрыто модератором, Пушок (?), 17:12 , 19-Июн-23, (86)

Скрыто модератором, n00by (ok), 17:16 , 19-Июн-23, (88)

Скрыто модератором, Пушок (?), 17:17 , 19-Июн-23, (89)

Скрыто модератором, n00by (ok), 17:29 , 19-Июн-23, (91)

Скрыто модератором, Пушок (?), 17:35 , 19-Июн-23, (93)

Скрыто модератором, n00by (ok), 06:03 , 20-Июн-23, (141)

Скрыто модератором, Пушок (?), 11:06 , 20-Июн-23, (153)

Скрыто модератором, n00by (ok), 16:32 , 20-Июн-23, (167)

Продвижение Bcachefs в состав ядра Linux, Дедобот (?), 17:07 , 19-Июн-23, (85) +1

ZFS c Btrfs можно подумать сильно популярная ФС А тут какое-то чудо-юдо им идёт, Аноним (6), 11:22 , 19-Июн-23, (5) –1

Узкий сегмент и узкая приминяемость в каком-то совем датацентреРешили свою задач, Аноним (110), 22:52 , 19-Июн-23, (110) +1
Btrfs ом пользуется миллиард фэйсбучных юзерей Если это не популярная фс, то чт, Аноним (174), 00:08 , 20-Июн-23, (117) +2

А Minix используют все у кого процессор Intel, значит Minix тоже популярная опер, Аноним (125), 00:39 , 20-Июн-23, (125) +4

пофиксил, Аноним (151), 10:14 , 20-Июн-23, (151) +3
Ну а что, нет чтоли А линукс использует уже наверное и пара миллиардов, с андро, Аноним (-), 19:27 , 20-Июн-23, (185) +1

Ну если применять логику, что все пользователи фейсбука используют btrfs, то мож, Stellarwind (?), 11:41 , 22-Июн-23, (233) +1

Примерно так и есть А еще у каждого найдется по нескольку устройств с линем, от, Аноним (-), 19:29 , 24-Июн-23, (238)

Стоит ли транслировать своё местечковое мнение на всех, демонстрируя свою огран, Чукча (?), 15:49 , 20-Июн-23, (163) +1
А разве в Убунточке по умолчанию не BTRFS , Аноним (186), 19:50 , 20-Июн-23, (186)
Желаешь судить по популярности ZFS планировалось открыть в OpenSolaris, чего Su, Аноним (207), 03:40 , 21-Июн-23, (207) –1

Правильно, тормозить так во всем Чтобы даже 64-битным процам неудобно было И н, Аноним (239), 19:33 , 24-Июн-23, (239)

Что-нибудь одно , YetAnotherOnanym (ok), 11:26 , 19-Июн-23, (9) –3
То, что в бтрфс ниасилили и видимо уже никогда ниасилят , но осилили в openZFS , аНОНИМ (?), 11:28 , 19-Июн-23, (11) +4

Буквально пару версий назад радикально заделали для RAID5 - а для RAID1 10 никог, Аноним (-), 00:18 , 20-Июн-23, (120) +3

И как оно write hole пропал А заполнение целиком одного диска из трёх рандомом, аНОНИМ (?), 18:47 , 20-Июн-23, (175)

У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в с, Аноним (188), 20:07 , 20-Июн-23, (188) +1

Ну зашибись, в следующем LTS потестирую И тем не менее, OpenZFS устроило срач в , аНОНИМ (?), 12:25 , 21-Июн-23, (215)

Это если что в 6 2 или 6 3 кернеле было Решение компромиссное, изначально была , Аноним (225), 22:48 , 21-Июн-23, (225)

Отказ девайса это всё же немного другая ситуация, когда точно известно что данны, аНОНИМ (?), 18:32 , 22-Июн-23, (235)

Я просто не понимаю что вы тестировали и зачем - реально устройства ТАК не отказ, Аноним (240), 03:03 , 25-Июн-23, (240)

Чем больше снапшотов, тем сильнее btrfs тормозит Число сильно ограничено , Аноним (173), 18:42 , 20-Июн-23, (173)

С какого кол-ва снапшотов, например, btrfs становится в 2 раза тормознее , аНОНИМ (?), 18:51 , 20-Июн-23, (177) +1
КО справедливо для любой ФС со снапшотами И не говорите, что ФС, созданная ген, Аноним (186), 19:54 , 20-Июн-23, (187)

В сабже автор довольно сурово уперся на эту тему Не помню, но он кажется смог д, Аноним (-), 02:09 , 21-Июн-23, (200)

https docs kernel org filesystems nilfs2 html, Аноним (212), 11:16 , 21-Июн-23, (212)

1 Жесткий технический лимит на число снапшотов и импакт на перфоманс это 2 разн, Аноним (-), 22:54 , 21-Июн-23, (226)

10 лет развивали, развивали а потом решили пересесть на рустик и ещё 10 лет в, Аноним (14), 11:53 , 19-Июн-23, (14) +3

Скрыто модератором, Аноним (-), 12:11 , 19-Июн-23, (20)
10 лет btrfs развивали-развивали, а тольку практически никакого - как была глючн, Анонимусс (?), 12:48 , 19-Июн-23, (29) –1

бтрфсу конечно не хватает некоторых фич, но других фич не хватает и openZFS Но , аНОНИМ (?), 14:42 , 19-Июн-23, (47) +1
Сильно лучше стало Оно у Facebook на продакшн стоит Это тебе не васянские локал, Витюшка (?), 14:52 , 19-Июн-23, (55)

То что они стоит у ФБ не значит что подойдет для васянского локалхоста У ФБ ресу, Аноним_5 (?), 15:45 , 19-Июн-23, (72)

Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему, Аноним (-), 00:21 , 20-Июн-23, (121)

им пофигу - это не их данные Да, теряли, и не один раз А чотакова, ты котиков , пох. (?), 13:29 , 21-Июн-23, (220)

А знаешь что, мистер умник Ты похрани-ка такой объем данных - для такого числа , Аноним (227), 23:35 , 21-Июн-23, (227)

мне - нахрен оно не надо, у меня другой бизнес, не слежка за всем миром в смысле, пох. (?), 11:12 , 22-Июн-23, (231)

Скрыто модератором, Аноним (-), 03:18 , 25-Июн-23, (241)

И главное - основной разработчик btrfs Он то 100 в курсе как выпиливать данные, bOOster (ok), 08:39 , 21-Июн-23, (209)

или ему просто наплевать Тут, правда, у изрядной части шайки все так же - этой д, пох. (?), 11:13 , 22-Июн-23, (232)

бриллиантовый камент для любителей раста Обычным людям это фсчудище и bcache на, Аноним (212), 12:45 , 19-Июн-23, (27)

Бриллиантовый камент для любителей бриллиантовых каментов A good craftsman ca, Аноним_5 (?), 12:56 , 19-Июн-23, (31)

Remember they won t use 10K horsehair brush for woodcutting because it s just po, Tron is Whistling (?), 14:43 , 19-Июн-23, (49)

балаболили они Так же, как другие по совершенно другому поводу балаболили не кр, Аноним (32), 13:01 , 19-Июн-23, (32) –1

Не, ну чего ты так про энтузиастов, обидно ведь Вообще не понятна претензия к по, Анонин (?), 13:32 , 19-Июн-23, (37) +1

Не, Rust же i386 поддерживает, он даже древние микроконтроллеры без mmu поддержи, Аноним (32), 14:23 , 19-Июн-23, (43)

Не увидел там балабольства Чел пишет хочу раст, потому что не люблю дебажить ко, Анонин (?), 14:41 , 19-Июн-23, (45) +3

Балабольство у тех, кто заявляет, что Rust не будет обязательным, а не у автора , Аноним (84), 17:06 , 19-Июн-23, (84)

Так раст и не обязательный Просто не пользуйся этой ФС или всем что зависит от , Анонин (?), 17:34 , 19-Июн-23, (92) +1

А, понятно Linux - для RedHat лично Спасибо, что напомнили , Аноним (102), 21:29 , 19-Июн-23, (103)

ну зачем же ты так Есть еще другие платиновые спонсоры Линукс для них - тоже А, пох. (?), 17:04 , 21-Июн-23, (223)

Актуальная реализация вообще на си А про планы с хрустом - але, гараж, пока в к, Аноним (-), 00:24 , 20-Июн-23, (122)

Мне, как пользователю, нах не нужно неотлаженное гамно, х як, х як и так сойдет,, Sw00p aka Jerom (?), 08:37 , 20-Июн-23, (146)

Опечатка, там былоно у меня что-то зрение село в последнее время, мимо нужных кл, Аноним (32), 14:26 , 19-Июн-23, (44)

Ешьте дети ext4, будете здоровы А прочий кaл оставьте корпоративным психам, они, Аноним (36), 13:29 , 19-Июн-23, (36) +1

ext 2 3 4 - cамые блевoтные ФС, - для девочек которым пофиг что ставить Точнее , pavlinux (ok), 14:46 , 19-Июн-23, (51) –7

Это ты не хочешь понять что эти твои фичи модненьких ФС это маркетинговый буллши, Аноним (6), 15:51 , 19-Июн-23, (76) +3

Ну да, замененный глючный проц, пару планок битой RAM, текучие SD flash и глючны, Аноним (-), 00:28 , 20-Июн-23, (123)

ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по д, Аноним (83), 17:06 , 19-Июн-23, (83) +1

Могу посоветовать использовать NTFS Там, конечно, бывают неудаляемые файлы, и д, Аноним (102), 21:32 , 19-Июн-23, (105) +2

Да ладно И как воспроизвести Бэкап готового глюка хоть есть , U202204161753 (?), 22:07 , 19-Июн-23, (109) –2

Я такое часто видел, но не не могу утверждать, по какой причине это происходит , Аноним (15), 12:08 , 20-Июн-23, (157)

многотерабайтный дамп где-то там посыпавшейся ntfs Можно восстановить в VM На , U202204161753 (?), 18:58 , 20-Июн-23, (178)

Бэкапа нет, как и диска чтобы его хранить Я - админ локалхоста Проблемный диск, Аноним (194), 22:41 , 20-Июн-23, (194)

Ти кто, пилять, xyета Анонимная, советовать он может Тебе имя своё стадно пи, pavlinux (ok), 00:19 , 24-Июн-23, (236)

На самом деле на пользовательском уровне отличия очень даже очевидны ext2 без ж, Kuromi (ok), 17:18 , 19-Июн-23, (90)

Ага, конечно, в перспективе разве что, Аноним (39), 13:47 , 19-Июн-23, (38)
супер, пройдет еще с десяток лет до принятия в ядро, пока он там все перепишет , Аноним (40), 14:01 , 19-Июн-23, (40)

Поэтому он сначала отправит в ядро, а потом начнет переписывать , Анонус (?), 14:49 , 19-Июн-23, (54)

Сначала его отправят как Шишкина, а потом он скажет что его притесняют , Аноним (6), 15:52 , 19-Июн-23, (78)

Кэш - это временная свалка, для быстрого доступа Нахуа помойке снапшоты и резер, pavlinux (ok), 14:48 , 19-Июн-23, (53) +3

Когда у тебя помойка под петабайт, а её сброс приведёт к отказу в обслуживании , _hide_ (ok), 15:00 , 19-Июн-23, (60)
При записи на ФС данные идут на быстрый твердотельный накопитель, откуда фоном, n00by (ok), 17:13 , 19-Июн-23, (87)

DRAM- SSD- HDD, Sw00p aka Jerom (?), 08:47 , 20-Июн-23, (147)

Автор путает CoW и RoW , Unnamed Player (?), 14:52 , 19-Июн-23, (56)

А ты ешь ,кушаешь или жрёшь D , pavlinux (ok), 14:55 , 19-Июн-23, (58) –1

Реализация в корне отлична , Unnamed Player (?), 15:05 , 19-Июн-23, (61) +1

CoW - это абстрактная хрень, нюансы зависят от авторов Кто-то FIFO называет CoW, pavlinux (ok), 15:42 , 19-Июн-23, (70)

Однако у них есть и ряд типовых общих свойств Например использование ресурса на, Аноним (-), 02:20 , 21-Июн-23, (202)

Чем отличается от lvmcache ext4 Файловая система в курсе что кешировано, а ч, Аноним (57), 14:53 , 19-Июн-23, (57)

Нормальным менеджментом стоража в стиле btrfs вместо всей этой замшелой и кривой, Аноним (-), 02:20 , 21-Июн-23, (203) +1

Дальше не читал Автор может и дальше пользоваться своей ФС Еще одна недописанн, keydon (ok), 15:21 , 19-Июн-23, (64) +1
Спасибо, но я лучше reiser5 подожду , Аноний (?), 15:28 , 19-Июн-23, (66) +1

Кстати, а когда выйдет Ганс райзер Я реально жду новый РайзерФС от ганса , Аноним (96), 18:03 , 19-Июн-23, (96)

Следующая попытка прошения помилования в 2026, Аноним (100), 19:53 , 19-Июн-23, (100)

Ему же вроде в 23 должны были дать , Аноним (102), 21:33 , 19-Июн-23, (106)

Живым не выйдет Он проявил гордыню, не продемонстрировал покорность, посмел отк, Аноним (102), 21:45 , 19-Июн-23, (107) –3

Гордыня предшествует падению Не зря так говорят Если с вами вообще тима работат, Аноним (-), 20:18 , 20-Июн-23, (189)

а ты с ним сидел чтоли , Аноним (212), 12:35 , 22-Июн-23, (234)

И этот вляпался , Аноним (96), 18:02 , 19-Июн-23, (95) +1

Модно, стильно, молодежно Иначе грантик не дадут, Neon (??), 19:04 , 20-Июн-23, (180)

Интересно что они там такое хотят блочное кешировать Во-вторых, есть кеш ОС, ес, fuggy (ok), 21:19 , 19-Июн-23, (101) +1

При этом и те, и другие 8212 консьюмерский отстой, которым большие операторы , Аноним (104), 21:51 , 19-Июн-23, (108)
Сейчас уже и некоторые SSD с гигантским кэшем на сотни гигов Вот только этот к, Аноним (136), 04:01 , 20-Июн-23, (136) –2

И че толку от этого кэша если интерфейс по факту SAS SATA , bOOster (ok), 08:46 , 21-Июн-23, (210)

Что-то там включают-выключают в ядро, а может просто починить повышенную нагрузк, нах. (?), 06:49 , 20-Июн-23, (143) –2

На Linux-libre этот глюк тоже наблюдается , vbcnthfkmnth123 (ok), 08:35 , 20-Июн-23, (145)
Чего это она повышенная мышка же хорошо двигается, быстро Почему бы не загрузит, Аноним (148), 09:33 , 20-Июн-23, (148)
Это какой дохлый комп нужно иметь, чтобы USB-Mouse - давала повышенную нагрузку , Neon (??), 19:06 , 20-Июн-23, (181) –1

А по русски написать сложно было , Аноним (144), 07:43 , 20-Июн-23, (144)

Нажимай исправить и пиши, что сложно , Аноним (148), 09:33 , 20-Июн-23, (149)

Я, конечно, понимаю, что это скорее всего перевод, но этот акцент на обновлении , Пряник (?), 09:54 , 20-Июн-23, (150)
Вот уже напрягает стабилизация реализации снапшотов Что там стабилизировать , Пряник (?), 10:19 , 20-Июн-23, (152) +2

_запись_То, чего zfs не умеет в принципе, ее снапшот всегда readonly А если теб, пох. (?), 16:06 , 20-Июн-23, (166)

В btrfs оно тоже красиво и интуитивно Большую часть дизайна Кент слизал оттуда,, Аноним (190), 20:27 , 20-Июн-23, (190)

вот вообще ни разу , пох. (?), 22:35 , 20-Июн-23, (193)

Да ну ладно тебе Если виртуализатором с снапшотами хоть раз в жизни пользовался, Аноним (-), 02:25 , 21-Июн-23, (204)

хинт - не все виртуализаторы - бредовые поделки на базе все той же единственнове, пох. (?), 13:24 , 21-Июн-23, (219)

Это о чем Я пользовался вмварью, гиперви, kvm и в конечном итоге, логика Co, Аноним (-), 00:12 , 22-Июн-23, (229)

снепшоты это история fs, как может быть интуитивной запись в них может быть ко, fidoman (ok), 02:09 , 21-Июн-23, (199)

Если кто смотрел sci-fi и понял концепцию параллельных вселенных, похожих, но с , Аноним (-), 02:34 , 21-Июн-23, (205)

Удачи потом это мержить , fidoman (ok), 14:54 , 07-Июл-23, (242)

Че за бред Snapshot с записью Отлично что ZFS проектировали не придурки, а люд, bOOster (ok), 08:51 , 21-Июн-23, (211)

Btrfs умеет и readonly снапшоты, более того RO RW снапшота можно менять через ро, Аноним (-), 00:25 , 22-Июн-23, (230) –1

Rust спасёт мир 9996 128548 , Минона (ok), 14:22 , 20-Июн-23, (161) –1

от bcachefs Ну не факт Пока это только идея, а в ведро того гляди уже включат , пох. (?), 16:02 , 20-Июн-23, (165)
Ага Соберет всех неадекватов в одном месте , Neon (??), 19:07 , 20-Июн-23, (182)
из компилятора раст сделают SDK с ограничениями как для андроида и все формально, Аноним (212), 11:35 , 21-Июн-23, (213)

Они и без раста собственность корпораций , Минона (ok), 12:38 , 21-Июн-23, (216)

нет, публикуя код в ядре ты не передаёшь права на него Но что толку от такого к, Аноним (212), 12:52 , 21-Июн-23, (218)

Растификация подсистем ядра Начали с драйверов, теперь - ФС, потом - планировщи, xsignal (ok), 18:07 , 20-Июн-23, (169)
По мнению автора Bcachefs, который любит программировать, а не отлаживать код, б, pashev.ru (?), 08:10 , 21-Июн-23, (208)
А достижения безгеморройности ext4 нет в планах Кстати, может, всё-таки Reiser4 , Аноним (214), 11:53 , 21-Июн-23, (214)

Уверен что в ней нет геморроя А почему не 5 , Минона (ok), 12:42 , 21-Июн-23, (217) –1

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

1. Скрыто модератором –25 +/–

Сообщение от DEF (?), 19-Июн-23, 11:06

Пусть этот поц сначала нормальное название своей ФС даст. Да и зачем нужна эта поделка, если уже есть Btrfs?

Ответить | Правка | Наверх | Cообщить модератору

2. Скрыто модератором +8 +/–

Сообщение от Аноним (2), 19-Июн-23, 11:09

>уже есть
что закапывать

Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором +12 +/–

Сообщение от Аноним (3), 19-Июн-23, 11:10

https://lore.kernel.org/linux-bcachefs/Yph4vK0KAjokd1UL@.../
Если кратко, то значительно более высокая производительность, поддержка кэширвоания на быстрых SSD и нормально работающие снапшоты.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

6. Скрыто модератором +/–

Сообщение от Аноним (6), 19-Июн-23, 11:23

А если btrfs это все пофиксят в новых релизах зачем нужен bcachefs?

Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором +5 +/–

Сообщение от Анонин (?), 19-Июн-23, 11:31

> А если
Вот ты сам ответил на свой вопрос.
Если сильно большой оптимист - можно еще задать вопрос "когда пофиксят?".

Ответить | Правка | Наверх | Cообщить модератору

18. Скрыто модератором +/–

Сообщение от Аноним (6), 19-Июн-23, 12:09

ASAP

Ответить | Правка | Наверх | Cообщить модератору

30. Скрыто модератором +3 +/–

Сообщение от asdasd (?), 19-Июн-23, 12:50

btrfs существует 14 лет, этот проект 10. У них все работает. Вопросы?

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

35. Скрыто модератором –1 +/–

Сообщение от Аноним (35), 19-Июн-23, 13:22

всё работает? посмешил

Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором +2 +/–

Сообщение от Аноним (77), 19-Июн-23, 15:51

Написано "все", а не "всё".

Ответить | Правка | Наверх | Cообщить модератору

195. Скрыто модератором +/–

Сообщение от torvn77 (ok), 21-Июн-23, 00:30

Работает то работает, но вот только в btrfs снапшот делается фиксацией содержимого файла и дозаписью изменений отдельно, что не требует создания отдельного архива, то в btrfs надо отправлять в буфер архив и хранить его отдельно, что что не только неудобно, но и приводит к избыточной пересылке информации.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

81. Скрыто модератором +/–

Сообщение от n00by (ok), 19-Июн-23, 16:54

В btrfs не пофиксят "поддержку кеширования на быстрых SSD", потому что там такого нет, надо использовать BCache.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

99. Скрыто модератором –4 +/–

Сообщение от DEF (?), 19-Июн-23, 19:30

>Если кратко, то значительно более высокая производительность, поддержка кэширвоания на быстрых SSD и нормально работающие снапшоты.
Это все есть в btrfs и снапшоты там работают отлично. Bcachefs (ппц, ну и название, назвал бы свою поделку BFS) - не нужна.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

113. Скрыто модератором +/–

Сообщение от Аноним (113), 19-Июн-23, 23:55

> Это все есть в btrfs и снапшоты там работают отлично.
Там есть 1 трабла: если на 1 экстент дофига референсов (например куча похожих снапшотов) - перфоманс может просесть. Это конечно специфичный случай но он есть. Дизайн bcachefs лучше адаптирован к такому случаю, "по итогам". Кент не будучи связан compat формата т.к. еще не в майнлайне - учел некоторые моменты. И по части перфоманса подрасперся конкретно.

Ответить | Правка | Наверх | Cообщить модератору

132. Скрыто модератором +/–

Сообщение от DEF (?), 20-Июн-23, 02:02

Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала без изменения формата Btrfs. Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и подводные камни, как только она станет популярной, как Btrfs.

Ответить | Правка | Наверх | Cообщить модератору

140. Скрыто модератором +/–

Сообщение от n00by (ok), 20-Июн-23, 05:59

> Я готов решить эту проблему,
> банально оптимизирую код
> и перепишу некоторый функционал
> без изменения формата Btrfs.
Вот это здорово, все бы так. ;)

Ответить | Правка | Наверх | Cообщить модератору

170. Скрыто модератором +/–

Сообщение от Аноним (-), 20-Июн-23, 18:13

> Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала
> без изменения формата Btrfs.
Не все известные проблемы решаются так. По итогам эксплуатации и выявленных проблем некоторые структуры сами разработчики btrfs'а делая это сегодня сделали бы уже иначе.
В частности, если интересно, см их идеи на тему "extent tree v2" (нечто типа формата хранения v2). Оно даже где-то в работе, но поскольку там могут сменить формат несовместимо (в том смысле что "v1" драйвер на старых ядрах не сможет такое читать) - пользуясь случаем, вероятно, попробуют и еще ряд вещей починить. Так что это тоже не быстро будет наверное. А почему это надо? Оказалось что при массовой параллельной нагрузке и быстрых сторажах extent tree имеет недетскими проблемы с lock contention. Это убивает параллелизм операций и тормозит. Там, кстати, сбежаввший из редхата Басик как раз и зажигает :)
При том как вы понимаете, никто не будет выбрасывать всю инфраструктуру драйвера и РАДИКАЛЬНО перепахивать формат. Заткнут очевидные проблемы наиболее простыми (по кодингу) способами. Что логично, не стоит сильно ломать активно эксплуатируемую кодовую базу.
Кент же глядя на это все и будучи еще не замайнлайнен разумеется мог позволить себе редизайн некоторых вещей, даже если это и ломает совместимость - ему не с кем совместимость еще держать, так что может сделать "как лучше технически" раз 1 черт кодить от и до. В этом у него как у более позднего дизайна, совсем без требований совместимости, и ожиданий что это немедленно годно к эксплуатации - определенная фора. Пока еще может позволить себе достаточно резкие маневры если удачная идея пришла.
> Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и
> подводные камни, как только она станет популярной, как Btrfs.
Несомненно при эксплуатации bcachefs вылезут какие-нибудь еще проблемы, которые сейчас тематические лица не предусмотрели, а тестирование новой кодовой базы с такими фичами и вышибание багов займет нехилое время. И возможно по итогам его эксплуатации кому-то захочется сделать другой дизайн, next gen next gen'а. Где устранят какие-то еще слабые места. Даже те о которых мы сейчас еще и не знаем.
Это у шишкина все просто - развел теорий, практикой не проверял, и так то все ЗБС. А в реальном мире с реальными хотелками юзерей и реальными заскоками железа получается совсем не так как теоретические CSники себе это воображали, ну их барахло и работает совсем иначе чем они себе мнили в дофига случаев. По факту приходится делать странные костыли для затыкания порблем, пересматривать приоритеты, узнавать много нового об устройствах, их свойствах и отказах, и вообще сталкиваться с неидеальностью мира во весь рост. И без всего этого файлухи не особо нужны. Скажем "а что файлуха сделает на 1 бэд секторе". Или "а вот кернел ресетит девайс 2 минуты, это развал райда или нет? И если девайс вернется, то что?"

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

126. Скрыто модератором +1 +/–

Сообщение от Аноним (126), 20-Июн-23, 00:49

> назвал бы свою поделку BFS
Название уже занято: https://en.wikipedia.org/wiki/Brain_Fuck_Scheduler

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

129. Скрыто модератором +/–

Сообщение от DEF (?), 20-Июн-23, 01:55

BCFS

Ответить | Правка | Наверх | Cообщить модератору

160. Скрыто модератором +/–

Сообщение от Аноним (160), 20-Июн-23, 13:14

Учитывая что та же красншляпа на БТРФС забила есть определенные сомнения что там что-то будут фиксить.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

162. Скрыто модератором +/–

Сообщение от Чукча (?), 20-Июн-23, 15:46

Красношляпа стала панацеей? Может просто нежелание вкладываться в чужое достижение?

Ответить | Правка | Наверх | Cообщить модератору

179. Скрыто модератором +/–

Сообщение от Аноним (-), 20-Июн-23, 18:59

> Учитывая что та же красншляпа на БТРФС забила есть определенные сомнения что
> там что-то будут фиксить.
На саму шляпу забили практически все известные по фс и блочному уровню ядерщики. Они и маются чем-то непонятным с пыхтонрасией в сратисе и гальванизацией XFS неизвестно зачем (точнее, известно, другого уже и не осталось - не jfs же им было брать?!).
А вот Басик - вот тот самый, который раньше в редхате был - подсел на вот именно пиление именно бтрфс чего-то. Только теперь у него даже мыльник не редхатовский чего-то. А остальные из редхата и еще раньше слились.

Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

8. Скрыто модератором +5 +/–

Сообщение от Аноним (8), 19-Июн-23, 11:25

Чем больше файлух, тем лучше. Конкуренция, все дела. Да и Шишкина позлить тоже приятно. Наверняка разродится еще одним "разгромным" интервью.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

52. Скрыто модератором +/–

Сообщение от Вы забыли заполнить поле Name (?), 19-Июн-23, 14:46

Что за разгромное интервью?

Ответить | Правка | Наверх | Cообщить модератору

94. Скрыто модератором +1 +/–

Сообщение от Аноним (94), 19-Июн-23, 17:43

Да, кстати... Очень даже к месту!
"Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято."
https://habr.com/ru/articles/559014/

Ответить | Правка | Наверх | Cообщить модератору

104. Скрыто модератором +/–

Сообщение от Аноним (104), 19-Июн-23, 21:32

Ну и как, трудоустроился Шишкин на ближайший десяток лет со своим поделием или пришлось на галеру идти?

Ответить | Правка | Наверх | Cообщить модератору

112. Скрыто модератором +/–

Сообщение от Аноним (112), 19-Июн-23, 23:50

> Ну и как, трудоустроился Шишкин на ближайший десяток лет со своим поделием
> или пришлось на галеру идти?
Его величество развело кучу умствований и при том ... ВАУ - "ещё не определился с тем, как их реализовать для простых Reiser4 томов". Это он так про снапшоты. Поэтому я пока поюзаю на btrfs, со всеми его неидеальностями, зато - вот - с снапшотами. Которые может и не идеально, но - вот - работают. Потом может сабж попользуюсь, я надеюсь дожить до этого момента.
А МакЛауды могут ждать когда его величество вообще осознает как к своему МегаИнновационному дизайну снапшоты вообще приделать. А сколько это накодить займет и тем более оттестировать до уровня стабильности не хуже хотя-бы btrfs вообще тактично помолчим - потому что люди столько не живут. Особенно если фича сразу не предусматривалась. Не та штука которую просто натянуть на глобус.

Ответить | Правка | Наверх | Cообщить модератору

111. Скрыто модератором +2 +/–

Сообщение от Аноним (-), 19-Июн-23, 23:21

> Linux block layer с файловой системой (дурной пример заразителен). И что
> характерно: там те же проблемы, что и в Btrfs.
Это на самом деле очень крутой tradeoff.
1) Все операции с RAID уровнем значительно быстрее т.к. оперируют только занятым местом, а не всей площадью.
2) Это намного гибче в плане возможности воткнуть "уж какие есть" девайсы в пул. Без канифолинга мозгов выравниванием по размеру и потерь места на этой почве. Или даже вынуть девайс после временного расширения пула под разовую задачу.
3) У таких штук изумительная реконфигурация и даже смена схемы хранения. Это как пересесть из ржавого жигуля в маленький персональный звездолет. Теперь все не прибито на гвозди и можно выбирать масштаб и конкретику по ходу дела. И сменить например схему хранения если вон то - не нравится.
4) На это все снапшоты и дедуп ложатся явно лучше чем то что было до этого. И уж тем более лучше чем это работает на чистом блочном уровне.
Btrfs создал новые паттерны по которым будут делать next-gen дизайны. Bcachefs продолжатель этого направления. Достаточно интересный. Сделанный с учетом проблем предшественников. И его кодер кажется может не только бла-бла на тему как надо, а конструктивную работу с апстримом на тему интеграции. В том числе и идти на компромиссы, и дорабаьывать core-подсистемы сообща. А не так что я тут отдельное нечто  в своей норке, а ващи проблемы меня не волнуют, дескать.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

168. Скрыто модератором +/–

Сообщение от Аноним (94), 20-Июн-23, 17:28

>1) Все операции с RAID уровнем значительно быстрее
А циферки-то где? Быстрее чем тут?
https://www.opennet.me/opennews/art.shtml?num=57026

Ответить | Правка | Наверх | Cообщить модератору

171. Скрыто модератором +/–

Сообщение от Аноним (-), 20-Июн-23, 18:30

> А циферки-то где? Быстрее чем тут?
Циферки зависят от процента используемого места. Скажем если пул был на 10 терабайт, но реально пока используется только 100 гигов - при конверсиях, добавлениях и изъятиях устройств и т.п. ворочаться будут только те 100 гигов как максимум. Т.е. разница относительно обычного райда во времени операции будет в десятки раз. Одно дело глупым райдом по всей площади рестрайп делать, другое - удвинуть или сконвертить только реально используемые 10% емкости. И это сильный и валидный аргумент "за" управление томами из именно файлухи. Если из блочного уровня - он не файлуха, не знает что используется. Это обрекает пользователей на медленные и печальные операции "по всей площади" даже если использовалось 10% емкости. Попытки что-то сверх того делать выглядели еще более убого, криво и проблемно потому что блочный уровень начинает лезть в явно ФСовские епархии, для чего он не создавался. Файлухам это виднее. Наверное мог бы быть какой-то общий уровень абстракции для этого - но пока таких дизайнов мало, не очевидно как такое могло бы выглядеть. Должны появиться эн разных дизайнов чтобы понять что там общее в этом аспекте. А пока есть btrfs (zfs не в счет, он вообще не это) да вот bcachefs в виде злостного WIP. Не дофига данных для новых подсистем и рефакторов.
> https://www.opennet.me/opennews/art.shtml?num=57026
Файлухи юзают не только ради циферок. И рейзер вообще умеет "space use aware" операции? Когда оно знает какой регион (не) используется и при конверсии схемы райд, изъятии девайса, уменьшении размера фс и проч - двигает только это? Кенту идея с backrefs и управлением пространством именно в контексте ФС тоже зашла и он тоже ее во многом содрал как я понимаю. Потому что это большой шаг вперед с точки зрения эксплуатации, что бы там шишкин не блеял. Подоткнуть первые попавшиеся девайсы для какого-нибудь разового расширения пула, а потом и быстро изъять эти девайсы бывает довольно круто. А шишкин такой номер вообще может показать для начала? Или у него только сказ про rampant layering violation? Это могут простить - если в замен предоставлены забойные фичи которыми обосновыается такая потеря эстетики и переизобретение колеса.

Ответить | Правка | Наверх | Cообщить модератору

191. Скрыто модератором +/–

Сообщение от Аноним (94), 20-Июн-23, 21:11

> Циферки зависят от процента используемого места.
Ну вот и поставь Btrfs в аналогичные условия. Создай том из нескольких дисков, на нём большой файл и замерь скорость удаления диска.
> Файлухи юзают не только ради циферок
От файлух требуется эффективно управлять дисковым пространством. То есть, компактно хранить данные и быстро проводить файловые операции, а также операции над томами. Остальное - это соревнования балерин по метанию молота.
> И рейзер вообще умеет "space use aware" операции?
Ненужно. См. выше.

Ответить | Правка | Наверх | Cообщить модератору

197. Скрыто модератором +/–

Сообщение от Аноним (197), 21-Июн-23, 01:36

> Ну вот и поставь Btrfs в аналогичные условия.
Аналогичные кому? Чему? Цель измерений? Вы вообще понимаете как это работает?
> Создай том из нескольких дисков, на нём большой файл и замерь скорость удаления диска.
По такому описанию я могу замерять что угодно. В любую сторону. Например, результат основательно зависит от числа дисков в конфигурации и % использования емкости.
Как простой пример, жил был системный диск. Механический. На 2 Тб. В пару ему такой же добавили, собрав в результате RAID1 порядка 2 Тб. Всего там несколько гигз было и рестрайп из single -> RAID1 занял жалкие считанные минуты. Потом диск захотелось утащить под другие нужды и RAID был превращен в single. Это тоже заняло несколько минут. Ну и вот за считанные минуты 2-терабайтный диск был вынут, просто потому что реальное использование было ессно и близко не 2 Тб.
А могу совсем наглый чит, с коэффициентом уделывания близким к бесконечности. В btrfs можно рестрайп делать не "жестко", а "мягко" - запросив тип для НОВЫХ чанков. Так все новые данные которые записывают с этого момента - будут в новом формате, а старые - останутся как есть. При этом в пуле будет смесь разных схем RAID. На самом деле это могло бы быть чуть не пофайловым решением - какую схему хранения тем блокам давать, дизайн так может, просто алгоритма таких решений для аллокатора нет. При вон той "конверсии типа RAID" - время операции крайне близко к нолю, так что win относительно более классических схем по времени приближается чуть ли не к бесконечности. На самом деле это конечно лишь доразвитие стиля CoW чуть дальше, но так можно было. И это может быть очень драматическим отличием от более классических схем по временам операций. Разумеется, есть нюансы. Скажем на полностью забитом диске никакого выигрыша относительно блочного райда не наступит. Если понимать вот эти фичи дизайна, можно ими пользоваться себе во благо. А еще, в дизайне где может быть смесь уровней RAID (данные и метаданные совершенно штатно могут иметь разную схему хранения даже без вон тех фокусов), сжатие, мульти-референстутые экстенты снапшотов и рефлинков, файлы с "дырками", и все такое - ответ на вопрос "сколько места свободно?" становится довольно интересным аспектом.
> От файлух требуется эффективно управлять дисковым пространством.
В случае RAID вынос его на файловый уровень основательно поднимает эффективность ряда операций, когда вместо жевания вон тех 2 терабайт от и до по всей площади оно удвинуло с диска несколько гигз которые есть за считанные минуты - и отдало мне диск из пула. Ну а на более классическом райде рестрайп 2-терабайтного пула на механических дисках будет оооооочень неспешной операцией. Если так вообще получится без разбора пула и сноса данных. Вон то видите ли нонстоп, при этом система работает, данные доступны.
> То есть, компактно хранить данные и быстро проводить файловые операции,
> а также операции над томами.
Ну и вот в части операций над томами, а точнее, пулом, в плане его увеличения, уменьшения, смены схемы хранения и проч btrfs может дать мастеркласс любой другой вундервафле. Это менеджмент как он должен быть, простой, ненапряжный, позволяющий использовать то что по факту есть без камасутр с выравниванием. А основанность на именно ФСовском уровне позволяет этому всему знать какое место используется а какие регионы можно совсем не трогать, что в случае частичной занятости зачастую крайне радикально ускоряет операции менеджмента с пулом.
И еще снапшоты. В итоге железный хост можно менеджить почти как VM - с множественными снапшотами состояний (даже writeable!), увеличить-уменьшить стораж когда надо, без особых напрягов, или даже рестрайпнуть в другую схему хранения. Без останова.
> Остальное - это соревнования балерин по метанию молота.
Не, вот извините! Пожив с снапшотами я уже на меньшее как-то не согласен. Всегда мечтал менеджить мои железки в стиле виртуалок. Или вот DUP на однодисковых конфигах мне очень нравится. Одно дело - кончина ОС, от 1 бэда, когда системная либа не прочлась и даже не грузится, и совсем иное - "csum failed .... corrected" при том же самом эвенте под той же либой - когда оно проблемный блок просто вынет из 2 копии в другом месте девайса, вероятность что и он тоже порушен - крайне маргинальная в реалистичных ситуациях типа 1 бэда раз в сколько-то (час..год). А еще как приятный бонус - отлично обнаруиживает сбойный хардвар, от гнилых SATA шнурков до глюкавых процов и чипсетов. Вопли "csum failed" извещают меня что проблема - есть. Очень на пользу безотказной работе систем.
Ну и еще я иногда data recovery балуюсь. Очень круто делать "копию" рефлинком чтобы какой-нить fsck гонять на нем. "Копия" чушки в пару терабайт делается за секунды. И ессно реально занимает только те блоки которые изменились. Примерно как CoW диски в VM по смыслу. Это конечно "thin provisioning" и реально там может и не быть места на полную копию, но мне и не надо, fsck какой не так уж и много блоков образа меняет. А если не получилось - окей, я сотру "провальную копию", сделаю новую, и попробую на ней другие подходы. Иными методами это все очень сильно медлленнее и требует супер-дофига места в сторажах, видите ли.
> Ненужно. См. выше.
Да им и снапшоты кажется не нужны. Остается только вопрос нафига рейзер нужен. Оверинженерии во, а бенефиты с этого - вообще какие? У btrfs понятно какие. Менеджмент хоста радикально улучшается и начинает по комфорту напоминать виртуалки, а если с умом пользоваться еще и выживаемость ОС улучшается, сбойное железо обнаруживается, и можно эффектные трюки рефлинками откалывать, типа "копирования" терабайтных чушек за секунды (для всех практических целей это ведет себя как независимая копия файла, хоть изначально и ссылается на блоки оригинала).

Ответить | Правка | Наверх | Cообщить модератору

222. Скрыто модератором +/–

Сообщение от Аноним (94), 21-Июн-23, 14:56

>> Ну вот и поставь Btrfs в аналогичные условия.
> Аналогичные кому? Чему? Цель измерений? Вы вообще понимаете как это работает?
Ты дурачок чтоль? Операции над томами должны быть быстрыми. Типичный пример - отобрать раздел у файлухи на ноутбуке, где просто так жесткий диск не всунешь. Btrfs у тебя будет целый день перемещать данные. Рейзер сделает это быстро.

Ответить | Правка | Наверх | Cообщить модератору

63. Скрыто модератором +/–

Сообщение от Аноним (63), 19-Июн-23, 15:20

Шишкие при чем тут?

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

118. Скрыто модератором +/–

Сообщение от Аноним (118), 20-Июн-23, 00:16

Он интервью давал, где критиковал все файловые системы кроме своей.

Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором +3 +/–

Сообщение от Аноним (10), 19-Июн-23, 11:28

Сейчас основная претензия к btrfs в том, что она падает от каждого чиха.
p.s. жду клованов, которые btrfs используют с детства и у них ни разу не было проблем. Я рад за вас, но другие не такие везучие.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

15. Скрыто модератором +5 +/–

Сообщение от Аноним (15), 19-Июн-23, 11:54

Это что ж у тебя за железо, что бтрфс падает от каждого чиха, неклован ты невезучий?

Ответить | Правка | Наверх | Cообщить модератору

17. Скрыто модератором +1 +/–

Сообщение от Аноним (6), 19-Июн-23, 12:07

А что есть те у кого ext4 падает от любого чиха? Вроде нет. А значит можно делать выводы о качестве фс.

Ответить | Правка | Наверх | Cообщить модератору

21. Скрыто модератором +2 +/–

Сообщение от Аноним (15), 19-Июн-23, 12:12

Если включишь поддержку чексумм и твоя память выдаёт ошибки, то и она вполне может развалиться "от каждого чиха", а так просто будут тихие повреждения в случайных местах и не всегда в важных. Кстати, по поводу каждого чиха. Сколько там уже десятилетий ext4 умирает при ресайзе, когда включен sparse_super2? И ведь не сообщали, что нельзя, видимо, "это знать надо".

Ответить | Правка | Наверх | Cообщить модератору

71. Скрыто модератором +/–

Сообщение от Аноним (6), 19-Июн-23, 15:44

Ещё если во время ресайза будешь стучать по диску отбойным молотком, то тоже будут тихие повреждения тебя что не предупреждали?

Ответить | Правка | Наверх | Cообщить модератору

158. Скрыто модератором +/–

Сообщение от Аноним (158), 20-Июн-23, 12:40

Зачем использовать sparse_super2 вместо sparse_super? Экономия на спичках? По умолчанию он отключен.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

159. Скрыто модератором +/–

Сообщение от Аноним (15), 20-Июн-23, 13:08

Там много чего может быть отключено по умолчанию, это не важно. Зачем тебе куча копий, когда хватит 2? Это может быть весьма ощутимо. Если это десяток дисков на сотни терабайт может и есть какой-то смысл (и то куда их столько), но в обычных то условиях куда?

Ответить | Правка | Наверх | Cообщить модератору

28. Скрыто модератором +2 +/–

Сообщение от leap42 (ok), 19-Июн-23, 12:46

> А что есть те у кого ext4 падает от любого чиха? Вроде нет. А значит можно делать выводы о качестве фс.
Ну есть 🤷‍♂️
Где-то уже описывал эту историю: сервер, ЖД. Шла где-то 30-ая минута fsck (тут вам не xfs, с её fsck по минуте). Свет снова прекратился (бесперебойники не успели зарядиться после полного опустошения), и fsck начался сначала. Шёл очень долго, кончился ошибкой. ФС сдохла и уже ничем не реанимировалась. Хорошо, бэкапы были.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

59. Скрыто модератором +/–

Сообщение от Аноним (15), 19-Июн-23, 14:56

Это точно про ext4, чем она занималась? Я тут начал волноваться, когда journal recovery минут 10 занял, обычно то моментально после обесточивания восстанавливает. Но это забитый диск и на его было записано прилично данных прямо перед обесточиванием. Тоже сейчас думаю отключат и приплыли, для этих данных то бэкапа и нет. На такие случаи должно быть резервирование, конечно.

Ответить | Правка | Наверх | Cообщить модератору

73. Скрыто модератором +/–

Сообщение от Аноним (6), 19-Июн-23, 15:46

У тебя диск быстрее закончился чем ФС.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

138. Скрыто модератором +1 +/–

Сообщение от leap42 (ok), 20-Июн-23, 05:33

> У тебя диск быстрее закончился чем ФС.
Неа. Я его переформатировал потом в XFS (v5 уже вышла, так что ей уже можно было пользоваться), и диск потом года полтора точно отработал. Дальше я уволился.

Ответить | Правка | Наверх | Cообщить модератору

102. Скрыто модератором +/–

Сообщение от Аноним (102), 19-Июн-23, 21:27

>сервер
>бесперебойники не успели зарядиться после полного опустошения
А зачем бесперебойники опустошили? Бесперебойник нужны исключительно чтобы корректно завершить работу. Если у вас сервер, то дейтацентр несёт ответственность за все последствия ненадлежащего оказания услуги.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

139. Скрыто модератором +/–

Сообщение от leap42 (ok), 20-Июн-23, 05:36

>>сервер
>>бесперебойники не успели зарядиться после полного опустошения
> А зачем бесперебойники опустошили? Бесперебойник нужны исключительно чтобы корректно
> завершить работу. Если у вас сервер, то дейтацентр несёт ответственность за
> все последствия ненадлежащего оказания услуги.
В целом согласен. Но тогда (это было лет 8 назад) я был админом в госухе с очень странными приоритетами и проектами, там такое считалось нормальным. Я ещё не знал как надо 🤷‍♂️

Ответить | Правка | Наверх | Cообщить модератору

16. Скрыто модератором +/–

Сообщение от Аноним (16), 19-Июн-23, 12:07

Да даже не то что падает, а то что архитектура переусложнена и это не фиксится. А то что падает - это уже следствие. Тут только выкидывать все наработки и переписывать с нуля.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

24. Скрыто модератором +/–

Сообщение от НяшМяш (ok), 19-Июн-23, 12:22

Я btrfs использую ради коров и снимков. Пока вроде работает. Но будет интересно посмотреть допилят ли bcachefs и будет ли инструмент миграции.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

114. Скрыто модератором +1 +/–

Сообщение от Аноним (114), 19-Июн-23, 23:59

> Я btrfs использую ради коров и снимков. Пока вроде работает. Но будет
> интересно посмотреть допилят ли bcachefs и будет ли инструмент миграции.
Немного конкуренции и выбора еще никому не мешало :). Да и итеративное развитие вперед никто не отменял. А раалии IO за последние лет 10 заметно изменились.

Ответить | Правка | Наверх | Cообщить модератору

25. Скрыто модератором –1 +/–

Сообщение от Аноним (118), 19-Июн-23, 12:29

Попробуй поставить на тестовый раздел/жёсткий диск и попробуй урони.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

26. Скрыто модератором +/–

Сообщение от Alladin (?), 19-Июн-23, 12:41

Подтверждаю

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

119. Скрыто модератором +/–

Сообщение от Аноним (118), 20-Июн-23, 00:18

Опровергаю.

Ответить | Правка | Наверх | Cообщить модератору

33. Скрыто модератором +1 +/–

Сообщение от Аноним (33), 19-Июн-23, 13:20

Кстати, подтверждаю. Буквально пару часов тому назад развалилась в виртуалке openSUSE Tumbleweed, на ровном месте -- просто перестала логиниться и всё. Причём без каких-либо действий с моей стороны, т.к. всё работало без нареканий (только загрузка и выключение очень долгие) со вчерашнего дня. Короче шляпа, а не ФС...

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

39. Скрыто модератором +2 +/–

Сообщение от Аноним (39), 19-Июн-23, 13:48

А как ты понял что дело в файловой системе?

Ответить | Правка | Наверх | Cообщить модератору

41. Скрыто модератором +1 +/–

Сообщение от Витюшка (?), 19-Июн-23, 14:04

А он и не понял. Это же эксперты с opennet. Понимать надо!

Ответить | Правка | Наверх | Cообщить модератору

42. Скрыто модератором –5 +/–

Сообщение от Аноним (33), 19-Июн-23, 14:15

Понять было не трудно, т.к. других причин просто не было. Другие дистрибутивы (да и суся на ext4) работают безотказно. Я даже разбираться не стал -- просто снёс эту срань да и всё. Но ты продолжай грызть кактус, не обращай внимания на "экспертов с опеннета".

Ответить | Правка | Наверх | Cообщить модератору

67. Скрыто модератором +/–

Сообщение от Аноним (35), 19-Июн-23, 15:33

и как связан логин с файловой системой?

Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором +2 +/–

Сообщение от Аноним (-), 20-Июн-23, 00:34

> Понять было не трудно, т.к. других причин просто не было.
Вот прям так, даже без лога системных сообщений - но виновата файлуха? :) Да неужели? Уровень системной экспертизы просто пробивает потолок. Подвального этажа. Глубокого бункера.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

156. Скрыто модератором –1 +/–

Сообщение от Аноний (?), 20-Июн-23, 11:27

А на кой ляд мне ломать голову что там за причины? Я устанавливал opensuse на виртуалку чисто для экспериментов с zfs (из-за доступности самых свежих её версий), а не для того чтобы чинить btrfs. Я просто переустановил её на ext4 -- теперь стоит как скала. Хотя если честно сейчас прям даже интересно стало. Надо было действидельно посмотреть что там было, чтобы, так сказать, документально засвидетельствовать фейл btrfs :-)

Ответить | Правка | Наверх | Cообщить модератору

174. Скрыто модератором –1 +/–

Сообщение от Аноним (174), 20-Июн-23, 18:45

> А на кой ляд мне ломать голову что там за причины?
Ну, как бы, если некто утверждает что виновата допустим файлуха (или лысый черт, или хренсгары) - подразумевается что он может свое утверждение как-то пруфануть или обосновать. С чем как раз вышел былинный отказ, как я понимаю.
> Я устанавливал opensuse на виртуалку чисто для экспериментов с zfs (из-за доступности
> самых свежих её версий), а не для того чтобы чинить btrfs.
И что в этом спиче доказывает что проблема вообще возникает из-за файлухи? Измышлизмы какого-то анона с виртуалкой?
> Я просто переустановил её на ext4 -- теперь стоит как скала.
А законы Мерфи вот гласят, что если вам кажется что дела идут хорошо - возможно вы просто чего-то не заметили. И откуда бы вот вам знать что дела идут хорошо, если в EXT4 вообще диагностируемость в районе плинтуса? Они на журнал то чексумы приделали лишь когда петух клюнул и потуги реплея рушеных журналов стали выносить тома. А на основной площади фс вообще чексум нет. И без полного журналирования (который там дико тормознут) эта штука вообще не парится об участи файлов при перезаписи. Можно спокойно получить файло которое наполовину старое и наполовину новое при крахе. Ведь инфо для undo или redo операции с данными там просто нет. А потом юзеры удивляются - чойта за марсианские пейзажи в некоторых фоточках и офисный док не открывается?!
> Хотя если честно сейчас прям даже интересно стало. Надо было действидельно
> посмотреть что там было, чтобы, так сказать, документально засвидетельствовать
> фейл btrfs :-)
Дык дерзай, если это что-то актуальное, только еще нехило бы указать детали конфигурации, для воспроизводимости эксперимента и понимания что на самом деле в нем видно.
Единственное что в бошку приходит - поставить unsafe кеширование диска виртуалки (когда оно не выполняет запросы VM на сброс кешей) и срубить это, но это как бы заведомо глючная конфига и факап именно в unsafe кешах. А в нормальной ситуации чего б ему там сыпаться хрен его знает.

Ответить | Правка | Наверх | Cообщить модератору

135. Скрыто модератором +2 +/–

Сообщение от Аноним (135), 20-Июн-23, 03:41

Лол, достаточно зайти в телеграм-канал opensuse. Там если тамблвид с чего-то не развалился, то день, считай, прошел зря. Тамошние обитатели только и делают, что обновляются и после этого восстанавливают систему из снапшотов. Арч с подключенным ауром и то надежнее.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

154. Скрыто модератором +/–

Сообщение от Аноний (?), 20-Июн-23, 11:16

С чего ей разваливаться? Я вот сейчас заново накатил её на ext4 (для экспериментов с zfs) -- работает как часы. А то что btrfs УГ я заподозрил сразу по её работе (до этого не сталкивался с этой ФС): очень медленный старт системы и такое же медленное завершение, что-то там монтирует-размонтируе, колдует, насоздавала кучу снапшотов, вольюмов, а в итоге не прошло и суток как система приказала долго жить )) Банально могло что-то неправильно отмонтироваться или примонтироваться, какие-то файлы повредились и привет. Ручаться конечно не могу что причина была именно в ФС, но за много лет пользования линуксами уже вырабатывается определённая интуиция, и при таких признаках моё подозрение сразу пало на ФС, т.к. ранее я с подобным не встречался даже на xfs. В общем, каждый пусть развлекается как хочет, но моё мнение об этой файловой системе (можете назвать это предубеждением) сложилось вполне определённое.

Ответить | Правка | Наверх | Cообщить модератору

142. Скрыто модератором +/–

Сообщение от Администратор (?), 20-Июн-23, 06:46

Использую btrfs как основную 3 года на разных железках. Это что нужно такое делать, чтобы btrfs падала? может у вас проблема с железом?

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

155. Скрыто модератором +1 +/–

Сообщение от t (??), 20-Июн-23, 11:18

использую btrfs уже примерно 10 лет, на всех личных дисках выбираю именно эту fs.
проблемы были встречал конечно. но так то строго говоря проблемы я встречал и с ext4, и с zfs, а сколько было их с ntfs, а до этого с fat32?
в целом fs - это всегда оценка рисков, и так чтобы поставил и забыл - фантастика, бекапы никто не отменял.
но так же есть хосты, где ext4 уже работает более 10 лет, и btrfs пулы, которые отрабатывали по >5 лет до вывода железа из эксплуатации.

Ответить | Правка | Наверх | Cообщить модератору

164. Скрыто модератором +/–

Сообщение от пох. (?), 20-Июн-23, 15:58

> Сейчас основная претензия к btrfs в том, что она падает от каждого чиха.
"уж чихнула, так чихнула!" (c)
Не от каждого. Основная претензия именно к непредсказуемости падения. Но очень сомнительно чтоб запиленная в одно жало более сложная мегаиерархическая фс была более надежной. Ну может хоть падать будет предсказуемо, и можно будет красными флажками огородить особо опасные места, типа raid6 btrfs. Но скорее всего - опять придется на границе один огромный красный флаг вешать.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

176. Скрыто модератором +/–

Сообщение от Аноним (-), 20-Июн-23, 18:49

> флажками огородить особо опасные места, типа raid6 btrfs. Но скорее всего
> - опять придется на границе один огромный красный флаг вешать.
Для тебя, пох, хоть автоматические туррели :)

Ответить | Правка | Наверх | Cообщить модератору

19. Скрыто модератором +2 +/–

Сообщение от maximnik0 (?), 19-Июн-23, 12:10

>Да и зачем нужна эта поделка, если уже есть Btrfs?
Авторы учитывают грабли на которые наступали в BTRFS,это уже + для  этой фс.
Охренеллый ++ я считаю рабочий fsck, даже в домашнем применения я сталкивался (правда без потерь данных) ошибку crc и только раздел в  чтение.Хорошо ошибку зафиксировали ,а чем ее починить ? scrub падал на 52 % проверки,fsck тоже так себе,не ремонтировал.(жесткий исправен,до сих пор пашет для бэкапов-от чего ошибка давно выяснил,в конверторе с ext была ошибка,починена 4 года назад) По новой форматировать? Так себе ремонт.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

116. Скрыто модератором +/–

Сообщение от Аноним (174), 20-Июн-23, 00:05

> Хорошо ошибку зафиксировали ,а чем ее починить ?
Избыточностью, лол. А если ее не было - упс - твоя конфига внезапно не предусматривала сколь-ниудь гарантированный и рабочий фикс без потерь. Чудес не бывает.
> для бэкапов-от чего ошибка давно выяснил,в конверторе с ext была ошибка,починена
> 4 года назад) По новой форматировать? Так себе ремонт.
Конверторы играют в весьма деликатную и сложную игру. Это типа-круто - но насколько это безопасно это так то отдельный вопрос. Там вон теперь ntfs2btrfs в тренде еще, желающим на грабли попрыгать еще вот тулса :))
А сабж наверное тоже так сможет, он унаследовал определенные черты дизайна - включая гибкость аллокаций. Это требуется для нормальной реализации ряда фич в таком дизайне. В первом приближении это называется "write-anywhere".

Ответить | Правка | Наверх | Cообщить модератору

128. Скрыто модератором +1 +/–

Сообщение от maximnik0 (?), 20-Июн-23, 01:38

> А если ее не было - упс - твоя конфига внезапно не предусматривала сколь-ниудь гарантированный и рабочий фикс без потерь.
Прикол в том что данные были целые, ошибка скорректировалась.А отремонтировать фс -упс....не может отремонтировать методанные.Это как с UDF , в последней ревизии двойная резервация методанных,а средств починки нет :-(

Ответить | Правка | Наверх | Cообщить модератору

183. Скрыто модератором +/–

Сообщение от Аноним (-), 20-Июн-23, 19:22

> Прикол в том что данные были целые, ошибка скорректировалась.А отремонтировать фс -упс....не
> может отремонтировать методанные.Это как с UDF , в последней ревизии двойная
> резервация методанных,а средств починки нет :-(
Если резерв метаданных есть то и чинить их не надо - а с чего им портиться? К тому же не любые метаданные можно вообще адекватно починить. Как максимум аннулировать проблему до состояния когда это монтироваться будет но в каком оно состоянии окажется - отдельный вопрос.
Эксплуатировать такое - тоже так себе радость, кто его знает как оно такое взбрыкнет при случае?
А если просто "данные выковырять" - так в btrfs в штатные тулсы офлайн читалка без монтирования встроена. Я не понимаю чего народ хочет. Чтобы все было збс даже на трухлявом железе прояпывающем данные и рушашем память? Так не бывает, я и дохлый нтфс у таких счастливчиков отскребал, но там тоже речь о монтируемости этого хлама уже не шла, только о get data back.

Ответить | Правка | Наверх | Cообщить модератору

192. Скрыто модератором +/–

Сообщение от maximnik0 (?), 20-Июн-23, 21:45

>Если резерв метаданных есть то и чинить их не надо - а с чего им портиться?
Ошибки имеют свойства накапливается.А потом упс,развалился том. Из за отсутствие средств ремонта фс -оказалась забыта UDF.Детская ошибка,до конца флаг разминирования драйвер под офтопиком (7-10) не отрабатывал .Данные целые,а работать с этим томом уже нельзя, и толку от дублирование метаданных и данных(опционально) ,если том идёт под формат.

Ответить | Правка | Наверх | Cообщить модератору

198. Скрыто модератором +/–

Сообщение от Аноним (-), 21-Июн-23, 01:53

> Ошибки имеют свойства накапливается.А потом упс,развалился том.
Btrfs их чинит по мере обнаружения, так что на активно юзаемой ФС не накапливаются как раз. Но если вдруг - во, теперь вы знаете занафига есть такая операция как scrub. Сие читает все используемые блоки и чекает чексуммы, чиня при необходимости.
И да, менеджмент такой штуки и особенности - отличаются от "классики". Это логично, блин. И сабж тоже будет отличаться от классики. Это просто другой набор паттернов дизайна файлух. Новый, необычный, непривычный. И все же обладающий рядом крутых и полезных свойств.
> Из за отсутствие средств ремонта фс -оказалась забыта UDF.
Для меня она забыта по совсем другим причинам: "а чем она лучше всех остальных ФС?". А вот ремонтировать ФС мануально я не очень хочу. Меня вообще автоматические и беспилотные применения волнуют - и как там это вообще могло бы выглядеть?! Так что отсутствие fsck бывает и фичой, когда в системе некому кнопки жать.
> Детская ошибка,до конца флаг разминирования драйвер под
> офтопиком (7-10) не отрабатывал
Чего-чего за флаг? Вы там в сапера режетесь? Или у вас отпуск с металлоискателем?
> Данные целые,а работать с этим томом уже нельзя, и толку от дублирование
> метаданных и данных(опционально) ,если том идёт под формат.
Ну как бы при нормальном выборе схем хранения и исправном хардваре и нормально работающей системе такая ситуация тупо не наступает, потому что "с хрена ли"? Ну вот как могут сбойнуть 2 блока RAID1 по 1 логическому смещению на разных девайсах? Если это случается, это индикатор убер-жирных системных факапов уже явно не уровня ФС и там и остальное не лучше. Такую систему фиксить надо ASAP. Не, я не спорю что как last resort такой тул может и вариант, но это не было в приоритете для того дизайна - и это понимаемо.

Ответить | Правка | Наверх | Cообщить модератору

206. Скрыто модератором +/–

Сообщение от maximnik0 (?), 21-Июн-23, 02:59

>Чего-чего за флаг?
Завершении сесии.В UDF многое взято с iso9660, усовершенствовали и приделали возможность работать с жёсткими и флэшками.Бага около 4-5 лет весела, в офтопике 10 в какой то ревизии исправили.
>"а чем она лучше всех остальных ФС?".
До расшаривания exfat -нет ограничения 4 Гб,имена юникод,кроссплатформенная,есть unix acl.

Ответить | Правка | Наверх | Cообщить модератору

130. Скрыто модератором –1 +/–

Сообщение от DEF (?), 20-Июн-23, 01:57

Btrfs уже более 10 лет в ядре и в продакшене у корпораций. Пусть Bcachefs наберет такую же популярность, как Btrfs, а там, я уверен, всплывут такие проблемы и баги этой ФС, что мама не горюй.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

46. Скрыто модератором +2 +/–

Сообщение от анон (?), 19-Июн-23, 14:42

Btrfs нужен пока для страданий, поэтому понятно, для чего эта поделка.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

134. Скрыто модератором +1 +/–

Сообщение от DEF (?), 20-Июн-23, 02:08

Юзаю Btrfs с 2012 года и не потерял ни одного бита. Железо свое глючное смени, стадалец.

Ответить | Правка | Наверх | Cообщить модератору

97. Скрыто модератором +/–

Сообщение от Аноним (-), 19-Июн-23, 18:27

> Пусть этот поц сначала нормальное название своей ФС даст.
> Да и зачем нужна эта поделка, если уже есть Btrfs?
Ну это вы зря так. Bcachefs структурально - списан с btrfs, но будучи сильно более поздним дизайном...
1) Учитывает проблемы всплывшие в btrfs и старается их обойти, взяв однако ж за основу удачную часть лекал. Т.е. крутое и удобное управление пространством в стиле btrfs, разные уровни RAID, снапшоты и проч.
2) Очень сильно оптимизирован на минимум оверхеда, в эпоху дизайна BTRFS это было намного менее критично. А сейчас появились сверхскоростные SSD и сеть, так что количество операций проца между всем этим - не пустой звук. Bcachefs оптимизирован на минимум оверхеда.
В общем если посчитать zfs Gen1 идей, btrfs был Gen2 а это примерно Gen 2.5+ по уровню эволюции мысли и учета ошибок предшественников. Он обещает стать примерно как btrfs, только еще теперь БЫСТРЫЙ. В смысле, спокойно дающий фору даже EXT4 и прочим. Даже на супербыстрых SSD.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

131. Скрыто модератором +/–

Сообщение от DEF (?), 20-Июн-23, 01:59

Btrfs уже более 10 лет в ядре и в продакшене у корпораций.Пусть Bcachefs сначала наберет такую же популярность, как у Btrfs. А потом у нее всплывут такие проблемы и баги, которые будут похлеще, чем у Btrfs.

Ответить | Правка | Наверх | Cообщить модератору

184. Скрыто модератором +/–

Сообщение от Аноним (-), 20-Июн-23, 19:24

> Btrfs уже более 10 лет в ядре и в продакшене у корпораций.Пусть
> Bcachefs сначала наберет такую же популярность, как у Btrfs. А потом
> у нее всплывут такие проблемы и баги, которые будут похлеще, чем у Btrfs.
Я думаю что у нее СНАЧАЛА всплывут проблемы сильно круче, потому что сырой код который впервые пошел в массы и поляна не вытоптана.
А потом - потом мир изменится, сторажи изменятся, IO и сети изменятся, и откуда б нам знать что тогда будет хорошо и плохо. Может все займет какой-нибудь MRAM который как RAM но - энергонезависимый, например? Тогда технологии хранения заметно поменяются.

Ответить | Правка | Наверх | Cообщить модератору

4. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Аноним (4), 19-Июн-23, 11:13

> он любит программировать, а не отлаживать код
99% современных кодерков именно такие

Ответить | Правка | Наверх | Cообщить модератору

7. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Аноним (8), 19-Июн-23, 11:23

ты понимаешь значение слова "отлаживать"?

Ответить | Правка | Наверх | Cообщить модератору

12. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от YetAnotherOnanym (ok), 19-Июн-23, 11:29

Поделись своим пониманием этого слова.

Ответить | Правка | Наверх | Cообщить модератору

23. "Продвижение Bcachefs в состав ядра Linux" +7 +/–

Сообщение от Random (??), 19-Июн-23, 12:19

Вычищать из кода лажу.

Ответить | Правка | Наверх | Cообщить модератору

22. "Продвижение Bcachefs в состав ядра Linux" +5 +/–

Сообщение от Самый Лучший Гусь (?), 19-Июн-23, 12:15

Отлаживать значит ложить на более далёком расстоянии чем сейчас

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

75. "Продвижение Bcachefs в состав ядра Linux" +4 +/–

Сообщение от Аноним (75), 19-Июн-23, 15:51

Устранять несоответствие между тем, что программист хотел написать, и тем что он написал в реальности.
И это важная часть любой разработки. если программист не хочет ей заниматься значит на выходе будет гавно. Язык программирования в той или иной степени может попытаться скрыть это гавно(сборка мусора в языках с GC), или не наступить на определенный вид граблей. Но видов граблей уйма, так что от дебага не уйти, если конечно хочется сделать продукт а не какашку.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

98. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (98), 19-Июн-23, 18:28

И ни один язык не спасёт программиста от неправильно применённых алгоритмов. Если условная видеоигра не умеет нормально отсекать геометрию вне камеры, то переписывание на новый технологический стек не поможет.

Ответить | Правка | Наверх | Cообщить модератору

69. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Аноним_5 (?), 19-Июн-23, 15:41

А написали бы "дебажить" как в оригинале
> loves to write code, but not to debug it
> just means a lot less time debugging
и никакого лингвистического спора не было бы))

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

172. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Neon (??), 20-Июн-23, 18:41

А нет никакого спора. Зачем обезьянничать, когда есть свои слова ?

Ответить | Правка | Наверх | Cообщить модератору

196. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от torvn77 (ok), 21-Июн-23, 00:34

На ютубе один лингвист высказал такое мнение: неправильных слов нет и если debug английское слово, то вот уже дебаг русское.(тем более что оно ещё и склоняемое, то есть не стоит особняком и полностью интегрировано в язык)

Ответить | Правка | Наверх | Cообщить модератору

221. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (221), 21-Июн-23, 13:31

> если debug английское слово, то вот уже дебаг русское
Железобетонная неоспоримая логика, конечно.
Давайте тогда "фуск" и "фак" добавим в лексикон русскоязычных людей.  Раз у лингвистов с YouTube нет "неправильных" слов.  Расширим и без того немалый запас ненормативной лексики.

Ответить | Правка | Наверх | Cообщить модератору

237. Скрыто модератором +/–

Сообщение от Аноним (-), 24-Июн-23, 19:27

Фак уже давно и прочно вошел в лексикон, как и прочие "ассо" явно являющиеся сокращениями от сами поняли чего :)

Ответить | Правка | Наверх | Cообщить модератору

82. Скрыто модератором +2 +/–

Сообщение от n00by (ok), 19-Июн-23, 17:02

>> он любит программировать, а не отлаживать код
> 99% современных кодерков именно такие
Боюсь, Вы перепутали "любят" и "умеют". Например, разработчики Rosa Linux не умеют. А я не люблю.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

86. Скрыто модератором +/–

Сообщение от Пушок (?), 19-Июн-23, 17:12

Держи нас в курсе как говорится

Ответить | Правка | Наверх | Cообщить модератору

88. Скрыто модератором +/–

Сообщение от n00by (ok), 19-Июн-23, 17:16

Давай адреса электропочты свой и своего друга, буду держать.

Ответить | Правка | Наверх | Cообщить модератору

89. Скрыто модератором +/–

Сообщение от Пушок (?), 19-Июн-23, 17:17

Здесь пиши, пожалуйста, чтобы все видели.

Ответить | Правка | Наверх | Cообщить модератору

91. Скрыто модератором +/–

Сообщение от n00by (ok), 19-Июн-23, 17:29

Ты не успел попасть в то время, когда в Сети повторяли "отучаемся говорить за всех"?

Ответить | Правка | Наверх | Cообщить модератору

93. Скрыто модератором +/–

Сообщение от Пушок (?), 19-Июн-23, 17:35

Успел. Рассказать как это было?

Ответить | Правка | Наверх | Cообщить модератору

141. Скрыто модератором +/–

Сообщение от n00by (ok), 20-Июн-23, 06:03

Расскажи, особенно интересно, почему тебя тогда не отучили говорить за всех.

Ответить | Правка | Наверх | Cообщить модератору

153. Скрыто модератором +/–

Сообщение от Пушок (?), 20-Июн-23, 11:06

На гитхапе у меня посмотри, я писал об этом.

Ответить | Правка | Наверх | Cообщить модератору

167. Скрыто модератором +/–

Сообщение от n00by (ok), 20-Июн-23, 16:32

Опеннет атакован экспертами, неотличимыми от Чат Жэпэтэ.

Ответить | Правка | Наверх | Cообщить модератору

85. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Дедобот (?), 19-Июн-23, 17:07

>кхе-кхе раньше было лучше

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Аноним (6), 19-Июн-23, 11:22

ZFS c Btrfs можно подумать сильно популярная ФС. А тут какое-то чудо-юдо им идёт на смену.

Ответить | Правка | Наверх | Cообщить модератору

110. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (110), 19-Июн-23, 22:52

Узкий сегмент и узкая приминяемость в каком-то совем датацентре
Решили свою задачу и выдали миру, а применять или нет ваше дело
Может вы только пасьянсом пользуетесь чего уж там какой кеш

Ответить | Правка | Наверх | Cообщить модератору

117. "Продвижение Bcachefs в состав ядра Linux" +2 +/–

Сообщение от Аноним (174), 20-Июн-23, 00:08

> ZFS c Btrfs можно подумать сильно популярная ФС.
Btrfs'ом пользуется миллиард фэйсбучных юзерей. Если это не популярная фс, то что ж тогда популярно то?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

125. "Продвижение Bcachefs в состав ядра Linux" +4 +/–

Сообщение от Аноним (125), 20-Июн-23, 00:39

А Minix используют все у кого процессор Intel, значит Minix тоже популярная операционная система.

Ответить | Правка | Наверх | Cообщить модератору

151. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Аноним (151), 20-Июн-23, 10:14

>используют всех, у кого процессор Intel,
пофиксил

Ответить | Правка | Наверх | Cообщить модератору

185. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (-), 20-Июн-23, 19:27

> Minix тоже популярная операционная система.
Ну а что, нет чтоли? А линукс использует уже наверное и пара миллиардов, с андроидами то. Пока какие-то ретарды про 1% пиндят.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

233. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Stellarwind (?), 22-Июн-23, 11:41

Ну если применять логику, что все пользователи фейсбука используют btrfs, то можно сказать что и вообще все пользователи интернета используют linux - явно больше пары миллиардов.

Ответить | Правка | Наверх | Cообщить модератору

238. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 24-Июн-23, 19:29

> Ну если применять логику, что все пользователи фейсбука используют btrfs, то можно
> сказать что и вообще все пользователи интернета используют linux - явно
> больше пары миллиардов.
Примерно так и есть. А еще у каждого найдется по нескольку устройств с линем, от телека до роутера. А майкрософт вещает про свои 1%. Им, понятное дело, с зафэйленым WinPhone считать с вон теми - неудобно.

Ответить | Правка | Наверх | Cообщить модератору

163. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Чукча (?), 20-Июн-23, 15:49

Стоит ли транслировать  своё местечковое мнение на всех, демонстрируя свою ограниченность?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

186. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (186), 20-Июн-23, 19:50

А разве в Убунточке по умолчанию не BTRFS?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

207. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Аноним (207), 21-Июн-23, 03:40

Желаешь судить по популярности? ZFS планировалось открыть в OpenSolaris, чего Sun Microsystems и добились открыв почти все исходники UNIX официально за исключением некоторых компонентов ядра что допиливали уже в проекте Illumos.
Сколько девушек тебе признавались в любви без твоего задаривания их чем-либо? Ты ведь хочешь по популярности у домохозяек оценить промышленную файловую систему без проблем с размером данных в принципе со 128 битным размером. Это только недавно стало так что 500 мегабайт, которые жрет ZFS по минимуму не такая большая часть от общей оперативной памяти. Плюс задействовать кеш данных через файловую систему вместо скажем кеша для Си исключительно чем плохо?
Ты просто мозгами шевелить не умеешь, вот тебе и нужны неопровержимые области применения. Но так как ты их не осилишь скорее всего такие как ты будут орать про ненужность. Ты наверное и медицину будешь орать что она ненужна пока тебе не понадобится. Смотрите какая непопулярная у людей восстановительная пластика лица у мужчин. Шрамы же мужчин украшают. Правильно, да?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

239. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (239), 24-Июн-23, 19:33

> 128 битным размером.
Правильно, тормозить так во всем. Чтобы даже 64-битным процам неудобно было. И не понятно будут ли в обозримом будущем 128-битные т.к. пока никто и близко не приблизился к порогу 2^64 байтов.
> Это только недавно стало так что 500 мегабайт,
А вон у того одноплатника с 256 оперативы - btrfs прекрасно работает. И сабж сможет. Какой грите процент оперативы 500 мегабайтов там? :) Случаи бывают разные.

Ответить | Правка | Наверх | Cообщить модератору

9. "Продвижение Bcachefs в состав ядра Linux и переписывание на ..." –3 +/–

Сообщение от YetAnotherOnanym (ok), 19-Июн-23, 11:26

> решить проблемы с высоким потреблением памяти при восстановлении и проверки ФС утилитой fsck
> использовать при разработке Bcachefs язык Rust
Что-нибудь одно.

Ответить | Правка | Наверх | Cообщить модератору

11. "Продвижение Bcachefs в состав ядра Linux" +4 +/–

Сообщение от аНОНИМ (?), 19-Июн-23, 11:28

>> - How does bcachefs avoid the dreaded RAID write hole?
> We're copy on write - and this extends to our erasure coding
> implementation, we don't update existing stripes in place -
> we create new stripes as needed, reusing buckets from existing
> stripes that still have data.
То, что в бтрфс ниасилили (и видимо уже никогда ниасилят), но осилили в openZFS.
>> - How does an O_DIRECT loop device on bcachefs compare to a zvol on ZFS?
> I'd have to benchmark/profile it. It appears there's some bugs in the way the
> loop driver in O_DIRECT mode interacts with bcachefs according to xfstests, and
> the loopback driver is implemented in a more heavyweight way that it needs to be -
> there's room for improvement.
То есть для образов дисков для виртуалок оно непригодно, как и btrfs. btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW образом диска и просто тормозит (в 2-3 раза медленее ext4) с no-CoW образом. Во втором случае ещё и остаётся без упаковки. в openZFS образы дисков в виде zdev просто ЛЕТАЮТ, быстрее чем голый диск работают. Не говоря уже о том, что упаковка на лету всегда имеется.
Про то чем лучше снапшоты так и не понял. в btrfs снапшоты просто замечательные, можно эн копий оси иметь например и грузиться по выбору в любую (пару раз пригождалось иметь новую и старую системы). В openZFS такое без доп ужимок и прыжков не выйдет (сначала надо снапшот сделать, потом его из снапшота преобразовать в полноценный датасет, а уж что делать чтоб забутиться из грёбанного initramfs в другой рут-датасет я даже не в курсе; в btrfs тупо в грубе выбирается аргументом ядру другой снапшот он же subvolume).

Ответить | Правка | Наверх | Cообщить модератору

120. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Аноним (-), 20-Июн-23, 00:18

> То, что в бтрфс ниасилили (и видимо уже никогда ниасилят)
Буквально пару версий назад радикально заделали для RAID5 - а для RAID1/10 никогда и не было актуально из-за наличия чексум. Так что реально проблемы есть только с RAID6. И кстати метаданные могут быть в другой схеме - том же RAID1 - что очень полезно в вон том плане.
> То есть для образов дисков для виртуалок оно непригодно, как и btrfs.
> btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW
> образом диска и просто тормозит (в 2-3 раза медленее ext4) с
> no-CoW образом.
По этой причине в Btrfs можно выбрать no-cow для конкретных файлов внезапно. И в сабже тоже можно будет. И да, делать двойной CoW и виртуализатором и ФС - тупая идея. Оставьте кого-то одного на этом пути. Либо RAW диск виртуалки и COW файлухой, либо COW диск виртуалки и nowcow файл. А вот cow cow'а - идея поганая.
> Не говоря уже о том, что упаковка на лету всегда имеется.
Она имеется также у btrfs и сабжа :)
> выбору в любую (пару раз пригождалось иметь новую и старую системы).
При том если делать как оно в убунте (2 subvolume, а истинный / файлухи вообще на 1 уровень выше / системы)  - еще и system и data можно раздельно снапшотить и откатывать. И спрятать уровень менеджмента от софта при нормальной работе ОС (например чтобы не повредить случайно).
> рут-датасет я даже не в курсе; в btrfs тупо в грубе
> выбирается аргументом ядру другой снапшот он же subvolume).
Ну да. Выбирается какого subvolume монтировать как / что довольно удобно. А операции с оными похожи на диры по сути. Стереть subvolume можно даже каким-нибудь миднайтом, как "директорию". Удобно так то.
Впрочем самые зачетные фичи btrfs это возможность подоткнуть или вынуть девайс с увеличением/уменьшением места, или даже схему хранения переиграть. И это все просто, шустро (только реально занятое место) и без останова системы. Можно даже device add -> new drive -> remove -> old drive -> прописать бутлоадер -> вы только что заменили rootfs device под ОС на ходу :). По своему забавно - сменить диск под системой нонстоп. А что, Шишкин, сможешь так же? :)

Ответить | Правка | Наверх | Cообщить модератору

175. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от аНОНИМ (?), 20-Июн-23, 18:47

> Буквально пару версий назад радикально заделали для RAID5 - а для RAID1/10 никогда и не было актуально из-за наличия чексум. Так что реально проблемы есть только с RAID6. И кстати метаданные могут быть в другой схеме - том же RAID1 - что очень полезно в вон том плане.
И как оно? write hole пропал? А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а) тоже переживает? OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не переживало. Но то было несколько лет назад.
> По этой причине в Btrfs можно выбрать no-cow для конкретных файлов внезапно. И в сабже тоже можно будет. И да, делать двойной CoW и виртуализатором и ФС - тупая идея. Оставьте кого-то одного на этом пути. Либо RAW диск виртуалки и COW файлухой, либо COW диск виртуалки и nowcow файл. А вот cow cow'а - идея поганая.
Во-1, я о том и сказал, что no-CoW файлы с образом диска виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят. Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть (ну или почти), и наоборот, летают быстрее голого диска. Это всё на свежесозданных пустых ФС.
> Она имеется также у btrfs и сабжа :)
Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет паковаться (и фрагментироваться). Например, 1 мегабайт. Меньше не будет. А в btrfs оно само будет резать на кусочки килобайт 128 упакованного - 16 неупакованного. А если в середину экстента с 128к данных байт записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.
> самые зачетные фичи btrfs это возможность подоткнуть или вынуть девайс с увеличением/уменьшением места, или даже схему хранения переиграть.
Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый тоже имеется.
Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2 дисках (и 2 sparse файлах на рамдиске, после чего те файлы отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками с loop deviceами.
А ещё, в OpenZFS шифрование по-датасетно искаропки. В btrfs вроде ещё не довпилили, хотя грозятся.

Ответить | Правка | Наверх | Cообщить модератору

188. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (188), 20-Июн-23, 20:07

> И как оно? write hole пропал?
У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.
> А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а)
> тоже переживает?
Это не имитация битфлипа, т.к. от оригинальных данных вообще ничего не останется, даже суперблоков, и нельзя ЭТО идентифицировать как девайс пула. Буквы дисков это прекрасно но их порядок при загрузке не гарантирован. В случае полного отказа девайса, если НИЧЕГО вообще нет, логичнее замену девайса делать, с ребилдом порушеного на новый. Но если это все постепенно - будет орать про чексумы и фиксить их, куда оно денется?
Из _реалистичных_ проблемных сторажей точно переживает работу на текучках и сыпучках с DUP (так можно юзануть фиговую флеху/карту, одну). Просто берет и чинит - и теорвер так намного прикольнее. Теперь проигрыш не при 1 бэде в чем-то критичном, а при совпадении когда бэды сразу в 2 копиях - в физически разных местах - что довольно маловероятно. Вот так теорвер гораздо прикольнее ощущается. "Еж пищит, орет, но живет".
> OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не
> переживало. Но то было несколько лет назад.
Они все же несколько разные по структуре. И если на девайсе вообще ничего не осталось - он не опознается как свой за отсуствием суперблоков. Но если на стораже не осталось нифига вообще, это replace девайса уже, а не фоновый фикс нифига. Т.к. полный отказ.
А с реалистичной точки зрения что-то сравнимое я видел только при слете транслятора на дешевом хламе типа карт и флех - и в этом случае всяко потребуется мануальщина для замена развалившегося вдрызг девайса. Пытаться такое чинить не стоит: склонно разлетаться вновь, даже если кажется что вроде починилось, реально та еще мина получается.
> Во-1, я о том и сказал, что no-CoW файлы с образом диска
> виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят.
Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.

> Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть
> (ну или почти), и наоборот, летают быстрее голого диска. Это всё
> на свежесозданных пустых ФС.
Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс. Это какое-то извращение понятное только ZFSникам. Я конечно понимаю что гребля только с девайсами и размерами слишком скучно, надо еще и вон той гребли добавить. А btrfs так то о простом и ненапряжном менеджменте. В гробу я видел управление какими там vol'ами дополнительно к остальному еще. В btrfs управление сводится по сути к add/remove/replace девайсов да может смене схемы. Удобно. А если стало мало места, можно подоткнуть +1 девайс. Ну может ребаланс пнуть если использование устройств сильно асимметричное вышло. Прокатит даже с RAID1 или там RAID5 каким. Без академической гребли с выравниваниями, рестрайпами, размерами и проч. За одно это авторам дизайна памятник надо поставить имхо.
> Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет
> паковаться (и фрагментироваться).
Насчет блоков: видите ли, это вовсе и не фича. Потому что, внезапно, не extent based дизайн даже еще! А какой-то block-based переросток. В чем трабл? Без ломового подпора рамой такой дизайн тормозной аки трактор! А btrfs почти как ext4, даже на роутере с 64 метрами оперативы (попробуйте там ZFS завести?!). Из-за этого как я понимаю на него рефлинки натянуть не смогли. Можно конечно поспорить за экстентные аллокаторы и их эффективность, но т.к. в целом мир выбрал для новых дизайнов их, они таки эффективнее в большинстве кейсов оказались. А btrfs живет даже на очень мелких конфигах, типа одноплатников и довольно непозорно я б сказал. Имея свои плюсы. Например, не дохнет от 1 бэда насмерть как EXT4. Да, представляете, 1 бэд под libc6 в EXT4 = система не грузится. То же самое на btrfs с dup - "csum failed ... corrected". Такая вот разница.
> Например, 1 мегабайт. Меньше не будет.
Ага, могу себе представить латенси всего этого и оверхед в менее удачных случаях, когда надо было 4К блок, а оно весь мег в результате кантовало.
> А в btrfs оно само будет резать на кусочки килобайт 128 упакованного -
> 16 неупакованного. А если в середину экстента с 128к данных байт
> записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.
Я это специально не проверял, но в среднем файлухи с сжатием и проч ведут себя вполне одупляемо в целом вроде. Наверное можно подобрать дурацкие случаи, но их для чего угодно подобрать можно.
> Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый
> тоже имеется.
Ну если дефраг это "техническое зло" то вот простое, гибкое и удобное управление + снапшоты это одна из вещей за которые есть смысл потерпеть необычные причуды инопланетного дизайна. Потому что менеджмент систем переходит на совсем иной уровень.
> Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2
> дисках (и 2 sparse файлах на рамдиске, после чего те файлы
> отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками
> с loop deviceами.
Так их почти вроде все на loop девайсах и собирают. Ну и это как-то не основной кейс чтобы меня сильно парить.
> А ещё, в OpenZFS шифрование по-датасетно искаропки.
А это разве не в оракле только? Или они таки доделали?
> В btrfs вроде ещё не довпилили, хотя грозятся.
Ну да. И это еще можно записать в минусы - т.к. хоть и решаемо иными методами, но в ущерб вон тому, удобному менеджменту. Что как бы несколько пролюбливает пойнт.
К сожалению продвинутость дизайна имеет и обратные стороны медали... https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@re.../

Ответить | Правка | Наверх | Cообщить модератору

215. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от аНОНИМ (?), 21-Июн-23, 12:25

> У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.
Ну зашибись, в следующем LTS потестирую.
> от оригинальных данных вообще ничего не останется, даже суперблоков, и нельзя ЭТО идентифицировать как девайс пула
И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные (все файлы) мне вернуло после такого, а после ресилвера вовсе как новое стало. Потеря суперблока на 1 девайсе не помешала. btrfs -- больше половины не вернуло. С рейд1 обе ФС вернули всё.
> Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.
Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt dist-upgrade -d делал, чтоб скорость качания не влияла).
> Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс.
Во-1 скорость виртуалок с таким девайсом получается заметно больше, чем просто с файлом, прокинутым в виртуалку как диск, т.е. есть какие-то оптимизации. Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно делать), независимо от других. Это два технических преимущества.
> Насчет блоков: видите ли, это вовсе и не фича.
Ну мне если честно по барабану что там внутри. Btrfs просто жутчайше фрагментирует файлы под торрентами или файл (CoW) с образом виртуалки. В первом случае кол-во фрагментов оказывается даже больше, чем кол-во кусков торрента (потому что после 1ого файла границы блоков торрента оказываются посередине блоков ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее установленного размер блока не рассыпется фрагментами (зато сосёт полным отсутствием дефрагментатора).
С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже внутри датасета, не говоря уж о том, чтобы между ними. В btrfs последнее легко, если разные subvolume оказываются в одном mount point'е, cp --reflink=always офигенно между субвольюмами "копирует" таким способом.
В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у меня* получается так, что под рут или под хомяк, если нет необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на рейдах -- openZFS.
> Ну и это как-то не основной кейс
Когда я переезжал с 2 дисков в мирроре на 4 в рейд6 (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним balance тут.
> А это разве не в оракле только? Или они таки доделали?
Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в шифрованный дестинейшн.

Ответить | Правка | Наверх | Cообщить модератору

225. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (225), 21-Июн-23, 22:48

> Ну зашибись, в следующем LTS потестирую.
Это если что в 6.2 или 6.3 кернеле было. Решение компромиссное, изначально была идея заворкэраундить write hole _без_ RMW, но с актуальным дисковым форматом таки оказалось "все сложно".
При том суть проблемы - и что можно делать на этот счет - описано в их вике и readthedocs. При сильном желании можно гонять и без фикса, НО - есть нюансы. А метаданные вообще имеет смысл всегда как RAID1 (data = raid5) или RAID1c3 (data = RAID6) держать, их обычно не очень много и это для метаданных более удачная идея.
> И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные
> (все файлы) мне вернуло после такого,
Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем? Если сторажу совсем плохо, его фирмварь при старте тоже не прочтет служебные регионы, девайс не выйдет на режим. Если кто видел винчи клацающие при старте, девайсы не проходящие идентификацию и проч, знакомьтесь, ОНО. SSD и некоторые иные флешастые еще в readonly уходят когда резерва не осталось. Но это тоже не то. А какой практически значимый отказ вон то тестит?
Такой полный отвал девайса рюхается даже глупым классическим райдом. И в реальном случае бенефит вообще в чем? При редком постепенном вероятностном развале, характерном для текучек и сыпучек (FEC не справился, фирмварь решил вернуть "уж что вышло" вместо IO error) - btrfs ничем не хуже работает, чинит чексумы и вопит в dmesg. И так то выживает даже на откровенном трешаке где ext4 ушатывается менее чем за месяц.
И еще мне не совсем понятно - если будет как бы тот же девайс на вид, но де факто совсем другой уже, может даже с чем-то нужным, как оно определит: можно ли туда вообще писат и его ли это девайс вообще? Не то чтобы проблемный кейс просто случайно создать но в случае btrfs я понимаю как это: на девайсе 3 копии суперблоков, в них UUID фс и generation, так что можно проверить и что это наша ФС и что девайс не выпадал надолго, фатально отстав от эволюции состояний пула. А вон то как избегает факапов в таких случаях? Оно не сможет "похожий" девайс присвоить при случае и развандалить? Та же нумерация девайсов при сканировании может меняться, скан асинхронный и параллельный нынче - "кто первый ответил тот и /dev/sda", грубо говоря.
> а после ресилвера вовсе как новое стало.
Да это то понятно. Btrfs после полного scrub сыпучки тоже все утекшие регионы чинит на ура. Как и при просто натыкании на это при чтении.
> Потеря суперблока на 1 девайсе не помешала. btrfs --
> больше половины не вернуло. С рейд1 обе ФС вернули всё.
На самом деле если данные реально надо - btrfs'ный дизайн в этом достаточно любопытен, т.к. точек входа на самом деле более 1 и если стало тухло можно попробовать немало вариантов альтернативного парсинга с немного более старых вариантов деревьев которые GC еще не подгреб. Запись же недеструктивная. Но тут я сильно лучше в btrfsном дизайне шарю чем в zfs'ном.
> Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt
> dist-upgrade -d делал, чтоб скорость качания не влияла).
Ну да блин, звездолет не очень ловко колесит по дорогам общего пользования. Но если вспомнить что у нас гиперпространственные движки есть, в отличие от лохов в пробках...
1) btrfs sub snap <system> </mgmt/before-upgrade>; sync; (снапшотим "систему сейчас")
2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
3) Если 2) зафейлился по любой причине, отваливаем на снапшот "before-upgrade". Если все прокатило ну, ок, тогда...
4) после всех проверок что результат устроил - стираем снапшот. Имеет смысл немного подождать и проверить весь софт до этого.
Зачем стоять на светофорах, если можно телепортироваться в назначение? А если не понравилась материализация в фонарный столб, сгонять на машине времени в прошлое, учесть препятствие, попробовать маневр еще раз, подкорректировав чуток :)
> Во-1 скорость виртуалок с таким девайсом получается заметно больше, чем просто с
> файлом, прокинутым в виртуалку как диск, т.е. есть какие-то оптимизации.
Зато менеджмент всего этого становтся просто адищем.
> Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно
> делать), независимо от других. Это два технических преимущества.
У btrfs в этом плане все сильно иначе, там subvolume всего лишь поддеревья (иерархии) с независимым снапшотированием. Это никак не отражается в блочные уровни а их райд "file based" как таковой. И в их дизайне вон то не имеет особого смысла. Я так понимаю что саням этот изврат надо было потому что у них не было управления девайсами и райдов в системе и они втянули классический варианто этого в ФС. Btrfs показал что не-классический вариант когда оно на уровне именно ФС - намного круче в менеджменте, имхо.
> Ну мне если честно по барабану что там внутри.
Не, вот на минутку, вы тут вещали что должно работать быстро. Или уж должно или уж нет. Моя ремарка - о том что "нативно" такой дизайн слоупок! А то что рамдиски быстрые - никто не сомневался. Только это не достоинство ФС и ее структур. И - внезапно - не катит без сотен рамы. Если сотен рамы на ломовой кеш нет (мир на файлопомойках не кончается) - ну оно и работает понятно как. А btrfs остается юзабелен даже на тощем роутере с мизером рамы, когда я ему в usb порт какойнить переносной винч с этим цепляю.
> Btrfs просто жутчайше фрагментирует файлы под торрентами
Вообще это зависит от кучи факторов. Я качал торенты и в зависимости от преаллокации, размера частей, и свободного места результат весьма варьируется. Ну и некто iZEN в свое время то же самое на zfs смог, догнав 3-дисковый пул (правда из ноутовых дисков) до чтения "аж" 15 мегов в секунду. При том там дефрага нет и очень интересно что он потом делал с столь крутым пулом, кроме пересоздания с ноля :). Настолько ушатать btrfs у меня не получалось, хотя, ок, у меня в многодисковых пулах с механическими дисками они все ж не ноутбучные, я не настолько мазохист.
> или файл (CoW) с образом виртуалки.
Опять же - все от конкретики сильно зависит. В данном случае от поведения виртуалки. Если виртуалка активно не пишет на диск - то и похрен вообще. Если пишет часто и мелко - ну, ой, фрагментируется конечно. Частично лечится увеличеением commit = и autodefrag в опциях монтирования, но вообще, у каждого дизайна есть сильные и слабые стороны. Логично юзать сильные и избегать слабые.
> ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее
> установленного размер блока не рассыпется фрагментами
Минимально вменяемые торентклиенты обычно обладают своим кастомным кешом, как раз поэтому, и не гасят мелкими записями такого размера. Типовые фрагменты от них это какие-то мегабайты. Ну и запись менее чем чанк торента смысла не имеет особо, а сейчас народ и 4-8 мегов юзает - для уменьшения размеров торентфайла.
> (зато сосёт полным отсутствием дефрагментатора).
Вот мне и интересно что потом iZEN с своим супер-пулом делал :)

> С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже
> внутри датасета, не говоря уж о том, чтобы между ними.
Это наверное как раз из-за блоков. В случае экстентов это заметно проще получается.
> cp --reflink=always офигенно между субвольюмами "копирует" таким способом.
Да оно и в пределах subvolume отлично работает. При этом оно просто 100% дедуп копии на старте, в уровень менеждмента не отсвечивает, именно "дешевый и сердитый дедуп" без ломового жрача проца и рамы, но логически это 2 разные копии.
Очень доставляет для data recovery: мастеркопию совсем не трогаем, а fsck и прочий дестрой на ее рефлинке. При номинальном размере в терабайтах реально создается за секунды, весит по размеру дельты, т.е. обычно немного, если не получилось, стереть попорченый рабочий образ, нарефлинкать за пару секунд новый и попробовать снова. Приятно себе оверсельнуть дохрена терабайтов под якобы-копию. Можно итеративно допинывать многотерабайтную чушку до кондиции не ожидая часами копирования и без мега-сторажей на 100500 терабайт, хранилка чуть больше образа нужна. А, надеюсь это объясняет почему возможность подоткнуть на время девайсов для расширения мне иногда полезна, а потом вынуть их и реюзнуть под иные цели.
> В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у
> меня* получается так, что под рут или под хомяк, если нет
> необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на
> рейдах -- openZFS.
Ну вот для файлопомоек в чистом виде zfs с его свойствами вполне ок... там обычно память все же не совсем мизерная, жрать ее особо некому, блочная природа дизайна не очень икается, соответственно. Но считать block based дизайн фичой относительно extent based я чисто технически отказываюсь, в целом скорее все же анти-фича. Ну вот не осталось желающих юзать блочные дизайны вместо экстентов в современном мире, что намекает.
> (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним
> balance тут.
Ну да, если места хватит - он это так делает: читает block group в старой схеме. Записывает в новую BG, с новой схемой, определяя чье это по backrefs. Апдейтит метаданные указывать на новый вариант. Освобождает старую BG. При чтении фиолетово в каком типа BG данные лежат, если половина в старой схеме, половина в новой - и похрен. Я даже крешил пару раз конверсию. Ну, после ребута возобновлял это дело да и дело с концом. Ничего не дохло. А вот с более классическими дизайнами я б так не рисковал - они откуда вообще знают прогресс конверсии допустим и как его возобновлять? Этой то штуке все просто - опять сканим bg в разбираемой схеме и переписываем их в новой, пока этого типа bg не останется. Т.к. cow-записи недеструктивные факап даже не портит данные по идее.
В принципе оно могло бы вообще хранить несколько типов BG для данных и по каким-то критериям более ценные данные так, менее ценне этак, просто этой логики нету в аллокаторе. Но сам дизайн мог бы даже такое. Это же позволяет мягкую конверсию, когда запрашивается новая схема отличная от старой и новые блоки идут в этой схеме, а старые так лежат в предыдущей. При этом можно "плавно" конвертить, операция оказывается дефернута в стиле cow.
> Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет
> кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в
> шифрованный дестинейшн.
А он это не чекает? Собссно btrfs fscrypt не сделал еще и потому что это странновато взаимодействует с мультиреференсами экстентов в _разных_ файлов, в fscrypt такое изначально не предусмотрели - для более простых фс делали. А совсем кастом они кажется не хотели, т.к. в принципе у fscrypt идея достаточно простая и как "менее параноидальное" шифрование вполне недурно смотрится.

Ответить | Правка | Наверх | Cообщить модератору

235. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от аНОНИМ (?), 22-Июн-23, 18:32

> Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем?
Отказ девайса это всё же немного другая ситуация, когда точно известно что данные там-то -- больше недоступны. И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их в принципе не сможет восстановить, а raid6 смог бы (если флипнулось только на 1 девайсе из N+2), но он этого не делает в принципе (я тоже проверял).
С другой стороны, я почитал старые крики btrfs-девелоперов о том что мол 'checksum on a checksum' (касательно хеша на блоки чётности) и то что они этого не сделали, потом посмотрел, что в openZFS всё чётко и изобрёл такой вот тест как в предыдущих мессагах описывал. Если openZFS выдюжило, то у меня 100% уверенность, что и любой случайный битфлип оно обнаружит и исправит. btrfs ниасилило -- ну значит и любой случайный битфлип может ниасилить, как раз из-за того, что не всё записанное на дисках рейда отхешено.
> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
Вот уже начинаются пляски с бубном :) (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ вхлам). А openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок диска под линейный лог зарезервирован -- как раз быстро флашить синхронные записи подряд, чтоб диск бошками не ездил отписывая новую версию дерева каждый раз. В btrfs, говорят, тоже такой лог есть, но факт остаётся фактом -- там было *МЕДЛЕННО*.
> Зато менеджмент всего этого становтся просто адищем.
Если имеется в виду менеджмент снапшотов то в openZFS он да, немного геморный, но только лишь потому, что они решили абстрагироваться от простой модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее, надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).
> Я качал торенты и в зависимости от преаллокации, размера частей,
Во1 насколько я понял, преаллокации в btrfs как таковой нет, т.е. она может делать sparse файлы конечно же, но заранее место и положение на диске для последующей записи не резервирует в принципе.
Во2, не очень понял про кеш торрент-клиента, какой бы он ни был по размеру, если он кратно меньше чем весь качаемый торрент, то совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало, и он всё равно будет вынужден отписывать данные в файлы рандомно. И тут-то бтрфс и рассыпется на тысячи фрагментов, причём если в торренте много файлов, то кол-во фрагментов, репортируемых filefrag раза в 2 больше оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов, которые часто и по-чутьчуть дописываются, видно как сначала 4к кусочек добавился, потом ещё 4к, потом десяток последних кусочков по 4к рраз -- и в один запакованный кусок по 2-3 блока упихали. А вот на торрентах, особенно многофайловых, он примерно никак.
> Собссно btrfs fscrypt не сделал еще и потому
Я вот как-то на тот фскрипт пытался смотреть, и понял что без бутылки я там не разберусь. Даже какая-то утилита на go нашлась, которая его позволяет чуть проще менеджить. В то же время менеджмент шифрованных датасетов в openZFS примерно на уровне сложности luks -- ввёл пароль/ключ и оно появилось, вынес ключ -- обратно исчезло. Даже проще luksа, там ещё поверх расшифрованного псевдодевайса надо маунтить-размаунчивать, а openZFS само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.
> А он это не чекает?
Проблема была в том, что если шифрованный пустой датасет создать на дестинейшене руками, то в него незашифрованный литься откажется, а если создавать вместе с началом заливки, то там были какие-то нетривиальные проблемы с указанием ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет на дестинейшене перед вливом при помощи ввода пароля).

Ответить | Правка | Наверх | Cообщить модератору

240. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (240), 25-Июн-23, 03:03

> Отказ девайса это всё же немного другая ситуация, когда точно известно что
> данные там-то -- больше недоступны.
Я просто не понимаю что вы тестировали и зачем - реально устройства ТАК не отказывают.
> И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их
> в принципе не сможет восстановить, а raid6 смог бы
В случае btrfs - сможет. В терминах RAID5 (минимальный пример): с1=a1^b1. Для a1 и b1 там чексум, отдельно, в метаданных, у метаданных может быть и иная схема, скажем raid1c3. Далее чекаем a1 и b1, если не сходится 1 из сум, XOR с parity и потом проверка по сумме еще раз. Сразу видим прокатило ли. Если померла парити, видно что a1^b1 != c1 хотя суммы верны, тогда c1 можно пересчитать из данных. Хранить и считать суммы блока c1 (парити) излишне.
> (если флипнулось только на 1 девайсе из N+2), но он этого не делает
> в принципе (я тоже проверял).
Btrfs может в отличие от обычного RAID делать более информированные решения из-за чексум.  Обычный RAID не имеет такого инфо, для RAID1 и RAID5 задник. Даже если мы видим несовпадения, неизвестно какая копия/блоки неверные. Чексумы позволяют это понять, улучшая свойства.
> 'checksum on a checksum' (касательно хеша на блоки чётности) и то
> что они этого не сделали,
Чексум на чексум проверяемый пересчетом из блоков данных не дает никакого нового знания, зато дает оверхед на счет и хранение. Хинт: чексумы блоков проверяют коректность данных, а парити считается из данных, можно сравнить посчитаное и сохраненное, поняв верен ли блок.
> и любой случайный битфлип может ниасилить, как раз из-за того, что
> не всё записанное на дисках рейда отхешено.
Я для себя предпочитаю чтобы ФС справлялась с реалистичными проблемами, а не тестами моделирующими ХЗ что: сторажи не отказывают вон так. А более реалистичные тесты на сыпучках (найденых btrfs'ом опять же) оно с должными схемами хранения переживает. Даже DUP - делает единичный проблемный девайс снова юзабельным, ценой ополовинивания. В древние времена он имел проблемы с repair т.к. не массовая штука. Но грю же - мы решаем проблемы совместными усилиями. В этом пойнт опенсорса.
>> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
> Вот уже начинаются пляски с бубном :)
Управление гипердвигателем лучше делать с иной семантикой чем ДВС, введя точные координаты в назначение. Личное телепание педальки и руля уже не актуально. И какой смысл бенчить реакцию на педальку, если я выкинул это действо совсем? Это еще быстрее. Сильно быстрее. Попробуйте, увидите.
При этом я имею инфо для полного, честного отката на known good, и даже время чтобы составить мнение - хочу я новое состояние или нафиг. На злобу дня, только что откатил неудачный апгрейд Deb12 -> Deb11. Железки на конкретной машине - взбрыкнули, разбираться прямща было не с руки, так что машина времени вернула как было - теперь можно НЕСПЕШНО пнуть причастных. В фоне. Пока все работает. А без снапшотов что б вы вообще делали? Бонусом writeable снапшотов, Deb12 на самом деле есть, и в writeable версии оного можно будет сделать тесты. Когда будет фикс.
> (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ
В пиковом случае дефраг есть. Что до fsync() его в последних нескольких ядрах разогнали в разы. Но я от этого в том кейсе ничего не выигрваю - в виде "а мы типа гипердрайв" я вообще не телепал руль и педальку. В этих терминах, весь dist upgrade - транзакция, уровня ФС. В виде подконтрольном мне. И я сам решаю потом, commit или rollback.
Да, эффективное и безопасное пилотирование звездного крейсера с гипердвигателем требует неких знаний CS. Но я был любопытным и нашел нужные лекции. И теперь могу комбинировать транзакции в эффективном виде сам, не глядя как "мы так привыкли" делают. Наука об осмысленном использовании знаний а не ритуалах и зубрежке.
> openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок
> диска под линейный лог зарезервирован --
В btrfs сие разогнали в разы последние пару ядер. Но как видите я просто пересмотрел что есть sync и точки начала-конца транзакции, это не костыль, это применение CS себе во благо. Работает намного круче глупого заучивания ритуалов.
> остаётся фактом -- там было *МЕДЛЕННО*.
Можете бенчмаркнуть с новыми кернелами типа 6.3 какого. Впрочем я с этого в вон том случае ничего не выиграю - вооооон то и так было супер быстрым. Даже пищет относительно последовательно. Inplace бы seek в патчимый регион делал, а cow это не надо и он с моим пересмотром семантики как раз свои сильные стороны выпятит, оформив записи куда ему там удобно и быстро. Да, я получаю полный журнал со скоростью безжурнальной фс.
> модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее,
Не вижу ничего геморного набрать btrfs sub snap <what> <where>.
> надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).
Не "надо" а "удобно делать так". Можно и иные варианты, просто уровень на 1 выше / с разными вариантами состояний вселенных, где мы можем путешествовать в ключевые точки пространства и времени - прикольная концепция. Логично что попадаем туда только после "сдвига измерений" (в более высокую абстракцию) содержащую в себе "все". Такой стиль понятен любому кто смотрел sci-fi и понимает концепцию ключевых точек, путешествий во времени и разветвления на мультивселенные с разным развитием событий. Это весьма буквальная реализация, writeable снапшоты тоже описываются этой идеей.
А так - subvolume при снапшоте не может содержать в себе subvolume (вместо него снапшотнется пустой дир): если сделать sub-in-sub, будет кольцевая зависимость экстентов друг на друга - и как это обрабатывать?! Не отменяет возможности снапшотнуть "что видишь" куда-то еще. Просто потом рулить менее удобно, а вон та абстракция "на уровень выше /" делает это удобным, логичным, и без "сдвига измерений" сложно снести снапшот нечаянно (по крайней мере файловыми операциями, типа F8 в миднайте на диру subvolume).
> Во1 насколько я понял, преаллокации в btrfs как таковой нет,
Это как бы не очень хорошая нагрузка для cow - но и сказать что фатальная и работать не будет - да вообще, работает. Просто если это основной кейс для стоража, btrfs может и не быть лучшим выбором, если записей много и часто так что дефрагнуть не вариант.
> Во2, не очень понял про кеш торрент-клиента, какой бы он ни был
> по размеру, если он кратно меньше чем весь качаемый торрент, то
> совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало,
Может пребуферить большие сегменты и записывать их 1 операцией. При этом число фрагментов здорово снижается: 1 дело экстенты по 10 кил, другое по 10 мегз. Суть одна, а соотношения разые, второй случай = в 1024 раза меньше метаданных! И это не только про CoW но и про проблемы экстентных аллокаторов вообще. И вы еще не видели что XFS делает если это соотношение фиговое. Никогда не видали DVD-sized торент стираемый минутами? На забитый XFS его качните без преаллокации. Экстентный аллокатор предсказуемо слепит мелких экстентов, получит неудачное соотнощение данные-метаданные, будет тормозить. Это 1 из мест где печальные блочные аллокаторы могли бы хоть чем-то блеснуть но у ZFS CoW на забитом стораже не даст развернуться и как показал дизайнерский пул "от iZEN" - тоже "не очень", и дефрага нет.
> и он всё равно будет вынужден отписывать данные в файлы рандомно.
Чем крупнее экстент тем ниже число фрагментов и лучше соотношение данных и метаданных: быстрее парсинг и линейный доступ. Блочным дизайнам пофиг, там парсинг всегда в наихучшем варианте, с описанием всей аллокации блоков, от чего они и тормозные.
Солидный кеш позволяет клиенту писать готовые блоки большими непрерывными экстентами. Грю же знание CS улучшает жизнь, позволяя ОСМЫСЛЕННО подыграть дизайну ФС...
> И тут-то бтрфс и рассыпется на тысячи фрагментов,
Вопрос в размере фрагмента и соотношении data-metadata. Экстентный аллокатор эффективен если экстенты большие. Zfs пролетает, у него нет экстентов как таковых и оно не может в большой экстент, так что обречено жевать много метаданных на аллокации ВСЕГДА. Поэтому ZFS даже в проекте не конкурент САБЖУ на суперскоростных SSD где низкий оверхед наше все.
> оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов,
Он в принципе любые экстенты пытается сливать. Но в торрентах больше поможет буфер клиента - тот к тому же эффективнее работает т.к. целенаправленно собирает чанки в более-менее непрерывные группы и может играть сообща с шедулером клиента "какие блоки просим у ремоты". Ну все минимально адекватные клиенты как-то так и делают, утягивая чанк(и) приличного размера, держа их в пребуфере пока не скачано целиком и не прошло верификацию и скидывая сразу солидные куски, чтобы экстентные аллокаторы не мучать плохим соотношением.
> на торрентах, особенно многофайловых, он примерно никак.
Там скорее буфер клиента актуальнее. И многофайловые ... в торентах обычно БОЛЬШИЕ файлы. Для кучи мелочи торент не эффективен, лучше упаковать. Хотя-бы чтобы сжать имена файлов которые в таком виде заметный % от данных. Чем-то типа 7z - умеющим жать оглавление архива.
> Я вот как-то на тот фскрипт пытался смотреть, и понял что без
> бутылки я там не разберусь.
Именно. У этого дизайна - довольно много краевых случаев. Это плата за продвинутость. Извините, мелкий аэропорт изначально не предусматривал что межзвездный крейсер захочет запарковаться.
> шифрованных датасетов в openZFS примерно на уровне сложности luks --
...тогда профит в чем? Fscrypt интересен простотой в сетапе и использовани, но в именно btrfs из-за мультиреференсов на экстент, тот fscrypt не делан с идеей что на 1 экстент более 1 раза можно сослаться. И это как бы трабл.
> само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.
У btrfs нет концепций из zfs, на самом фундаментальном уровне, связано с гибким аллокатором, и "файловой" природой RAID. Нет, никто не сдаст сильные стороны этого дизайна. Это весь пойнт его существования. Именно поэтому он nextgen и его просто менеджить. Крипто хорошо, но не ценой слома этой абстракции. Fscrypt в этом смысле наименее интрузивен, он не клещится с тем что хотел продвинутый аллокатор. Но в btrfs валидно 2 раза сослаться на 1 экстент как file1[10..20] и file2[30..40]. Btrfs на уровне дизайна волнует только чтобы блок был идентичного размера и содержимого, логическое размещение пофиг. А вот крипто обычно использует смещения для однозначного формирования nonce. И тут уже некие траблы. Нет, я не проектант запредельно крутых звездолетов и не выдам сходу хорошую логику на такой случай. Это хорошо работало для мелких самолетиков типа EXT4, а звездному крейсеру уже похуже. Но перспективнее вон того, где те понятия вообще не часть дизайна и вся идея дизайна это простое управление им а не жуткие костыли.
> ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых
> снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет
> на дестинейшене перед вливом при помощи ввода пароля).
Ну как бы продвинутым звездолетам свои проблемы походу. Только ваш звездолет - сделан из 4-моторного винтового самолета. Тот дизайн не задумывался для того что вы хотели, просто тогда лучше не умели. Так что вариабельно-блочный аллокатор максимум что из себя смогли вон те тогда выжать. Это имхо не есть лучшее решение. Мне экстентные в целом больше нравятся, все новые дизайны - экстентные, не просто так. Одна из причин по которым btrfs не особо тупит и без подпора гигазами рамы.

Ответить | Правка | Наверх | Cообщить модератору

173. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (173), 20-Июн-23, 18:42

Чем больше снапшотов, тем сильнее btrfs тормозит. Число сильно ограничено...

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

177. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от аНОНИМ (?), 20-Июн-23, 18:51

С какого кол-ва снапшотов, например, btrfs становится в 2 раза тормознее?

Ответить | Правка | Наверх | Cообщить модератору

187. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (186), 20-Июн-23, 19:54

КО: справедливо для любой ФС со снапшотами. И не говорите, что ФС, созданная гениальными Сантехниками, не так. Может, только большее количество снапшотов тянет.

Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

200. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 21-Июн-23, 02:09

В сабже автор довольно сурово уперся на эту тему. Не помню, но он кажется смог догнаться до миллиарда, чтоли, снапшотов. Не то чтобы это реально надо, но прошареный инженер строя лесопилку глядя на опыт предшественников все ж устроит алмазное напыление на зубьях, на случай если все-таки рельсу :). А если окажется мало то и парочкой индустриальных лазеров сдобрит. "Ухты@#$, так можно было?! Сказали о...е мужики"

Ответить | Правка | Наверх | Cообщить модератору

212. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (212), 21-Июн-23, 11:16

> В сабже автор довольно сурово уперся на эту тему.
https://docs.kernel.org/filesystems/nilfs2.html
> There is no limit on the number of snapshots until the volume gets full.

Ответить | Правка | Наверх | Cообщить модератору

226. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 21-Июн-23, 22:54

1) Жесткий технический лимит на число снапшотов и импакт на перфоманс это 2 разные аспекта, не находите?
2) У конкретно nilfs есть много других проблем, главная из которых - он довольно заброшенный. Потому что не, он не то чтобы чем-то плох, но когда вопрос "чем лучше остальных?" - у него нет крутого и гибкого управления btrfs, а на 1 девайсе, или с "классическими" вариантами управления томами это все слишком канительно и кто так будет бодаться когда btrfs уже есть, а тут и сабж еще?

Ответить | Правка | Наверх | Cообщить модератору

14. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Аноним (14), 19-Июн-23, 11:53

10 лет развивали, развивали... а потом решили пересесть на рустик и ещё 10 лет в мейнстрим это никто не возьмёт, потому что всё поменялось, опять всё фиксить... а потом надо будет опять фиксить фичи "как у ZFS и BTRFS" и перфоманс "чтобы ближе к ext4 чем к ZFS"

Ответить | Правка | Наверх | Cообщить модератору

20. Скрыто модератором +/–

Сообщение от Аноним (-), 19-Июн-23, 12:11

То есть как обычно

Ответить | Правка | Наверх | Cообщить модератору

29. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Анонимусс (?), 19-Июн-23, 12:48

10 лет btrfs развивали-развивали, а тольку практически никакого - как была глючным поделием, так и осталась. Ну ладно, не настолько глючным как 10 лет назад, но сильно лучше не стало.
Рустик уже в мейнстриме, первые дрова уже на подходе (ставлю на драйвер видяхи для яблока)
Чел наверное написал пару утилит и понял насколько раст лучше чем си, раз так написал.
И ему явно есть с чем сравнить - точно есть большой опыт написания кода на си))

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

47. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от аНОНИМ (?), 19-Июн-23, 14:42

бтрфсу конечно не хватает некоторых фич, но других фич не хватает и openZFS. Но вот насчёт глючности я бы поспорил. Я даже специально взгромоздил btrfs на раздел с торрентами, работает цуко и не глючит :) На рутовых разделах она тоже у меня живёт счастливо и радует снапшотами.
Конечно, всплывает такая хрень как ужасная фрагментация (по самой сути рандомных записей в файлы при качании торрентов), но встроенный дефрагментатор своё дело делает.

Ответить | Правка | Наверх | Cообщить модератору

55. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Витюшка (?), 19-Июн-23, 14:52

Сильно лучше стало. Оно у Facebook на продакшн стоит.
Это тебе не васянские локалхосты от икспердов opennet.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

72. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним_5 (?), 19-Июн-23, 15:45

То что они стоит у ФБ не значит что подойдет для васянского локалхоста.
У ФБ ресурсов - redundancy, бекапы, люди - намного больше.

Ответить | Правка | Наверх | Cообщить модератору

121. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 20-Июн-23, 00:21

> У ФБ ресурсов - redundancy, бекапы, люди - намного больше.
Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему. В этом месте интересы фэйсбука и локалхостов нехило совпадают.

Ответить | Правка | Наверх | Cообщить модератору

220. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 21-Июн-23, 13:29

> Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему.
им пофигу - это не их данные. Да, теряли, и не один раз. А чотакова, ты котиков сам же новых понавыложишь.
А вот потерять невосстановимо фотки умершего члена семьи у себя на локалхосте - это совсем другая история.
Так что нет, не совпадают даже приблизительно. Цель фейсбука - сделать максимально дешево и х-ево.
(рабы которые все это чинят - тоже максимально дешевые)

Ответить | Правка | Наверх | Cообщить модератору

227. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (227), 21-Июн-23, 23:35

> им пофигу - это не их данные. Да, теряли, и не один
> раз. А чотакова, ты котиков сам же новых понавыложишь.
А знаешь что, мистер умник? Ты похрани-ка такой объем данных - для такого числа юзерех - на чем там тебе удобно. Столько же лет. И мы посмотрим получится ли у тебя с твоими супертехнологиями вообще лучше если отмасштабировать до того же размера.
Понимаешь, чисто практически, если MTBF = 1 000 000 часов, и у тебя 1 девайс, ты скорее всего не доживешь до его отказа. Надежно типа. А если будет 1 000 000 девайсов по планете раскидано, "каждый час что-то ломается" может получиться. Надежно, типа? :)
Из вот этих соображений тестам "в масштабе" доверия несколько больше.
> А вот потерять невосстановимо фотки умершего члена семьи у себя на локалхосте
> - это совсем другая история.
Невосстановимо, в дизайне с недеструктивной записью и встроеной офлайн-читалкой и множественными точками входа для репарсинга - надо еще постараться, имхо. С более типичными файлухами если ситуация не идеальна - может хуже быть, у них запись же деструктивная и (мета)данных "есчо" чисто технически не остается, сразу и быстро, без возможности отменить или пересмотреть это вообще совсем. Ну и бэкапы не отменяли. Желательно в разных локациях. А то мало ли какие пожары, наводнения, химеры, тени, птички...
Я вон с ntfs твоего любимого testdisk+photorec вытаскивал недавно. Ну вот пролюбило оно имена файлов и аллокацию, что хочешь то и делай. Данные ессно на месте. К счастью оно не фрагментировано почти - а отсутствующие имена... чем крут линух? Можно накорябать сриптик, он пнет ffprobe и exiv2 после вон тех, позырит теги ... и через 5 минут оно лихо именует сотни тыщ фоточек и мувиков "как камера" - сгенерив имя по дате, из тегов. Через еще 5 минут все лихо переименовано и разложено лучше чем изначально :)
Но как ты уже понял, это - не заслуги нтфс. И не его штатного тулкита ФС. О которых в этой истории сложно сказать что-то хорошее.
> Цель фейсбука - сделать максимально дешево и х-ево.
Большинству юзерей энтерпрайзное железо тоже как-то дороговато, извини. А с чексумами хотя-бы глюкастики быстро замечаются. А нтфс какой они маринуют до последнего, понятия не имея что проблемы есть, пока не случится что-то типа вон того, когда там метаданные уже в хлам до состояния что это игнорить не получается.
> (рабы которые все это чинят - тоже максимально дешевые)
КМК по сравнению с тобой они - богатенькие буратины.

Ответить | Правка | Наверх | Cообщить модератору

231. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 22-Июн-23, 11:12

> Ты похрани-ка такой объем данных - для такого числа юзерех - на чем там тебе удобно.
мне - нахрен оно не надо, у меня другой бизнес, не слежка за всем миром.
> Столько же лет.
в смысле - сразу же половину прое..ть?
> получится ли у тебя с твоими супертехнологиями вообще лучше если отмасштабировать до того же
> размера.
а мне не надо того же размера. У меня совершенно другие задачи и вдобавок нет дешевых рабов (много жрут и гадят, а подвала нет, там бомбоубежище). И то что для мордокниги кажется приемлемым трейдофом - для меня недопустимо.
Я - не мордокнига, в этом и разница. Поэтому и никаких выводов в стиле "что хорошо мордокниге будет просто прекрасно и для меня". Нет, не будет.
"не все решения системных программистов подходят для прикладных" (с)
> Но как ты уже понял, это - не заслуги нтфс. И не его штатного тулкита ФС. О которых в этой
> истории сложно сказать что-то хорошее.
их заслуга - что мне за 25 лет существования ntfs и использования его в хвост и гриву - ни разу никакой фоторек использовать не пришлось и двоичным редактором ковыряться в своем диске тоже.
А вот про прекрасные файловые системы л@п4тых - я того же самого сказать не могу.
К счастью, с некоторых пор я использую их в стиле выкрасил и выбросил, никаких ценных данных на них не храня.

Ответить | Правка | Наверх | Cообщить модератору

241. Скрыто модератором +/–

Сообщение от Аноним (-), 25-Июн-23, 03:18

> мне - нахрен оно не надо, у меня другой бизнес, не слежка за всем миром.
Ну дык, и все же, с точки хранения данных у них вот есть базы по 20+ терабайт. Это довольно специфичная нагрузка и забавный стресстест для файлух.
> в смысле - сразу же половину прое..ть?
Ну дык, покажи как это у тебя получится, посмотрим будет ли лучше :)
> и вдобавок нет дешевых рабов (много жрут и гадят, а подвала
> нет, там бомбоубежище).
Бедный пох, у него подвал с батареей отжали под бомбарь.
> - для меня недопустимо.
Ну, я не мордокнига но мне btrfs тоже ничего.
> в стиле "что хорошо мордокниге будет просто прекрасно и для меня".
> Нет, не будет.
Для себя я знаю что сан с энтерпрайзными хранилками от меня и моих хотелок был еще дальше чем эти.
> "не все решения системных программистов подходят для прикладных" (с)
Не все. Но довольно многие. И обычно это в целом все же работает. А если наоборот - можно и жесткий, трудноустранимый треш получить. Фуксия подтвердит.
> их заслуга - что мне за 25 лет существования ntfs и использования
> его в хвост и гриву - ни разу никакой фоторек использовать не пришлось
А мне вот пришлось. Правда не на своих ntfs, но это потому что для себя шатал я это архаичное тормозилово юзать. А так btrfs мне тоже не приходилось особо чинить. Хоть у меня его и есть.
> и двоичным редактором ковыряться в своем диске тоже.
Да я это тоже не практикую. Однако предпочитаю понимать "свои" дизайны (активно используемые мной) - их сильные и слабые стороны, а потом - зачем бороться с законами мироздания если ими можно пользоваться?
> А вот про прекрасные файловые системы л@п4тых - я того же самого сказать не могу.
Зато btrfs меня предупреждает о глюках железа - и чинит единичные редкие бэды влет, не говоря про простое расширение сторажей вида "подцепил что было под рукой, получил эн места".
> К счастью, с некоторых пор я использую их в стиле выкрасил и
> выбросил, никаких ценных данных на них не храня.
Ну как бы если для тебя ntfs венец творения и ты юзаешь винду, твое мнение как и что должно быть в лине не очень ценно. Каки твои рассуждения о юниксвее, который для тебя же и не сработал в результате. А себе я не настолько враг чтобы камлать на технологии из 90х и наслаждаться проприетариями при этом всем. Я вообще не понимаю пойнт этого занятия. Вот наоборот - я стал в разы эффективнее и смог много новых кейсов (e.g. эмбедовка). А у тебя регресс какой-то уже.

Ответить | Правка | Наверх | Cообщить модератору

209. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от bOOster (ok), 21-Июн-23, 08:39

И главное - основной разработчик btrfs. Он то 100% в курсе как выпиливать данные из мертвого раздела, в отличии от шайки оголтелых...

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

232. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 22-Июн-23, 11:13

> И главное - основной разработчик btrfs. Он то 100% в курсе как
> выпиливать данные из мертвого раздела, в отличии от шайки оголтелых...
или ему просто наплевать.
Тут, правда, у изрядной части шайки все так же - этой дешевой порнухи новой накачают.

Ответить | Правка | Наверх | Cообщить модератору

27. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (212), 19-Июн-23, 12:45

> Just because you made a painting with a $10k horsehair brush and golden paint does not necessarily make it great art.
бриллиантовый камент для любителей раста. Обычным людям это фсчудище и bcache на ноутах с NVME только для замедления процессора и деградации аккума.

Ответить | Правка | Наверх | Cообщить модератору

31. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним_5 (?), 19-Июн-23, 12:56

Бриллиантовый камент для любителей "бриллиантовых каментов":
"A good craftsman cares about his tools. Listen to woodworkers who get together, they'll be talking about their tools just as much as the actual work. We're interacting with these tools every day, and the quality of the tool very much affects the quality of the work."

Ответить | Правка | Наверх | Cообщить модератору

49. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Tron is Whistling (?), 19-Июн-23, 14:43

Remember they won't use 10K horsehair brush for woodcutting because it's just pointless.

Ответить | Правка | Наверх | Cообщить модератору

32. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Аноним (32), 19-Июн-23, 13:01

>теперь безумно писать код на языке Си, когда появился лучший вариант. Rust уже задействован в Bcachefs
>Раст необязателен
балаболили они. Так же, как другие по совершенно другому поводу балаболили не краснея (но всем уже тогда было всё понятно), что реестр - это только для защиты детей.
Предлагаю прекратить этот клоунский маскарад, официально дропнуть в linux все платформы, для которых Rust не поддерживается (но из исходников фактическую поддержку не выпиливать и тестирование продолжать, но кто эти платформы в энтерпрайзе испольеует - тот пусть и решает, что ему дешевле, Rust допилить, или самим эти платформы дропнуть, от энтузиастов всё гавно как всегда толку 0, поэтому их мнение веса не имеет, если только они не готовы скинуться деньгами в достаточном количестве на fulltime-команду), и начать переписывать само ядро на Rust.

Ответить | Правка | Наверх | Cообщить модератору

37. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Анонин (?), 19-Июн-23, 13:32

> от энтузиастов всё гавно
Не, ну чего ты так про энтузиастов, обидно ведь.
Вообще не понятна претензия к поддержке платформ. Ты собираешься развернуть эту файлуху на мк или на каком-то древнем железе? Ну значит ты просто не сможешь это сделать. И всё.
Вот какой платформы тебе не хватает в раст?
> и начать переписывать само ядро на Rust.
О, наконец-то до людей доходить начало!

Ответить | Правка | Наверх | Cообщить модератору

43. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (32), 19-Июн-23, 14:23

Не, Rust же i386 поддерживает, он даже древние микроконтроллеры без mmu поддерживает. Это с платформами без llvm у него проблемы.
>Вот какой платформы тебе не хватает в раст?
Мне лично всех хватает пока. Но другим людям может не хватать. Это очень обидно и унизительно, когда твоё оборудование выкидывают, а тебя пускают по миру с голой жопой и так лучше не делать. Но мир у нас злой и циничный. И не надо это маскировать. Чем это виднее, тем быстрее до людей дойдёт, что так жить не надо и тем быстрее он станет нормальным. Поэтому было бы намного лучше, если бы вместо всякого балабольства нам бы говорили всё как есть. Не "мы делаем это для вашего же блага", а "нам вредно ваше благо, но вы жалкие, и нашим действиям никак не можете помешать".

Ответить | Правка | Наверх | Cообщить модератору

45. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Анонин (?), 19-Июн-23, 14:41

Не увидел там балабольства.
Чел пишет "хочу раст, потому что не люблю дебажить код".
Он делает это для себя - чтобы ему легче было писать код.
И саму фс он не просто так пишет - или для себя, или на заказ, или из любви к искусству.
Плюс он считает, что смена языка сделает код более надежным, т.е пользователям тоже станет лучше.
Но всем хорошо не будет никогда. Да и вроде никто этого и не декларировал, даже для си.
Потому что то, что код сможет скомпилится под другую платформу, совсем не значит что он будет там вообще работать.
> "нам вредно ваше благо, но вы жалкие, и нашим действиям никак не можете помешать".
Как-то слишком пафосно.
Тут скорее "мы делаем это для себя, а вы можете воспользоваться результатами НАШЕГО труда. Но если вам что-то не нравится - то или воспользуйтесь результатами еще чего-то труда, или вперед работать самим."

Ответить | Правка | Наверх | Cообщить модератору

84. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (84), 19-Июн-23, 17:06

> Не увидел там балабольства.
Балабольство у тех, кто заявляет, что Rust не будет обязательным, а не у автора файловой системы. Автор ФС - молодец, что делает исследования.
>Он делает это для себя - чтобы ему легче было писать код.
Вот пусть и держит тогда это out of tree. Без шансов найти широкое применение и всех подсадить на зависимость от Rustа. Как подсадили разрабы safetensors - теперь приходится ставить громадный растовый тулчейн и геморроиться с компиляцией только для того, чтобы pytorch мог прочитать сериализованные так модели.

Ответить | Правка | Наверх | Cообщить модератору

92. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Анонин (?), 19-Июн-23, 17:34

> Балабольство у тех, кто заявляет, что Rust не будет обязательным
Так раст и не обязательный! Просто не пользуйся этой ФС или всем что зависит от раста.
> Вот пусть и держит тогда это out of tree.
Охохо, ты будешь указывать разрабу и ментейнерам ядра что дедать?)) Самому не смешно?
Ну так не пользуйся safetensors - бери старые версии.
Или не пользуйся чужими сериализованными моделями.
Или вообще выкинь pytorch.
У тебя же куча возможностей. Еще раз - это всё делалось и делается не для тебя лично.

Ответить | Правка | Наверх | Cообщить модератору

103. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (102), 19-Июн-23, 21:29

А, понятно. Linux - для RedHat лично. Спасибо, что напомнили.

Ответить | Правка | Наверх | Cообщить модератору

223. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 21-Июн-23, 17:04

> А, понятно. Linux - для RedHat лично. Спасибо, что напомнили.
ну зачем же ты так? Есть еще другие платиновые спонсоры.
Линукс для них - тоже.
А ты перепоклонись-ка двадцать раз и colour на color и обратно поисправляй в своем ненужном редхату и мордокниге патче, а потом все равно пойди с ним нахрен потому что он кому-то чем-то не понравился.

Ответить | Правка | Наверх | Cообщить модератору

122. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 20-Июн-23, 00:24

> Так раст и не обязательный! Просто не пользуйся этой ФС или всем
> что зависит от раста.
Актуальная реализация вообще на си. А про планы с хрустом - але, гараж, пока в кернеле инфраструктуры для этого толком еще нет даже. И даже для сишной версии инфраструктуру то только начали адаптировать совместными усилиями. Так что сперва будет версия на си. А когда-нибудь может и на хрусте появится. А почему бы и нет, особенно если к тому моменту GCC'шный бэкэнд хруста будет в форме для билдовки ядра?

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

146. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Sw00p aka Jerom (?), 20-Июн-23, 08:37

>т.е пользователям тоже станет лучше.
Мне, как пользователю, нах не нужно неотлаженное гамно, х*як, х*як и так сойдет, пользователь отпишет свой комент

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

44. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (32), 19-Июн-23, 14:26

>всё гавно
Опечатка, там было
>всё равно
но у меня что-то зрение село в последнее время, мимо нужных клавиш промахиваюсь

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

36. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (36), 19-Июн-23, 13:29

Ешьте дети ext4, будете здоровы! А прочий кaл оставьте корпоративным психам, они должны страдать.

Ответить | Правка | Наверх | Cообщить модератору

51. "Продвижение Bcachefs в состав ядра Linux" –7 +/–

Сообщение от pavlinux (ok), 19-Июн-23, 14:46

ext/2/3/4 - cамые блевoтные ФС, - для девочек которым пофиг что ставить.
Точнее они даже не вдупляют различий, преимуществ  и отсутствие своих же требований.

Ответить | Правка | Наверх | Cообщить модератору

76. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от Аноним (6), 19-Июн-23, 15:51

Это ты не хочешь понять что эти твои фичи модненьких ФС это маркетинговый буллшит. Блестящая упаковка за которой ничего нет.

Ответить | Правка | Наверх | Cообщить модератору

123. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 20-Июн-23, 00:28

> Это ты не хочешь понять что эти твои фичи модненьких ФС это
> маркетинговый буллшит. Блестящая упаковка за которой ничего нет.
Ну да, замененный глючный проц, пару планок битой RAM, текучие SD/flash и глючные шнурки в коллекцию - маркетинговый булшит наверное, а не чексумы фс в деле, хехе :)
А вам из всего этого комп следовало бы свинтить, с вашим EXT4, посмотреть, заметите ли вы вообще подвох :))). Не, можете и таким железом пользоваться, типа сэкономили заодно. Какимнить геймерам сойдет наверное даже. Слетит система - переставят, впервой чтоли?!

Ответить | Правка | Наверх | Cообщить модератору

83. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (83), 19-Июн-23, 17:06

ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по дефолту.
Остальное либо под конкретную задачу, либо нестабильное, либо ограниченное.
Так что ты может и прав, но это тоже само по себе плюс.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

105. "Продвижение Bcachefs в состав ядра Linux" +2 +/–

Сообщение от Аноним (102), 19-Июн-23, 21:32

Могу посоветовать использовать NTFS. Там, конечно, бывают неудаляемые файлы, и директории, в которых они лежат, которые chkdsk терпит и ничего плохого не видит, зато есть хекс-редакторы с поддержкой парсинга, которыми можно их структуру в $MFT инвалидировать

Ответить | Правка | Наверх | Cообщить модератору

109. "Продвижение Bcachefs в состав ядра Linux" –2 +/–

Сообщение от U202204161753 (?), 19-Июн-23, 22:07

Да ладно ... И как воспроизвести?
  Бэкап готового "глюка" хоть есть?

Ответить | Правка | Наверх | Cообщить модератору

157. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (15), 20-Июн-23, 12:08

Я такое часто видел, но не не могу утверждать, по какой причине это происходит. Слишком рандомно возникает. Приходилось подмонтировать на запись с ntfs3g и удалять в ней, а это ещё хуже, потому что неизвестно, как она после неё будет работать и когда ей станет совсем плохо. Не совсем понимаю какие бекапы ты рассчитываешь увидеть, тебе отправить многотерабайтный дамп где-то там посыпавшейся ntfs, что ты с ним собираешься делать? И главное, зачем мне хранить эти дампы.
Всё гораздо интереснее когда файлы исчезают, повреждаются, или вся ntfs разваливается. И такое было. Тут хотя бы есть определённая закономерность, все фатальные повреждения случались в результате автоматического запуска chkdsk, которая уже автоматически всё разносила (я уверен до неё данные были целыми).

Ответить | Правка | Наверх | Cообщить модератору

178. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от U202204161753 (?), 20-Июн-23, 18:58

} многотерабайтный дамп где-то там посыпавшейся ntfs
Можно восстановить в VM.
На динамический .vhd / .vhdx
Удалить всё остальное кроме повреждённого каталога.
Вот со сжатием файла .vhd[x] есть неясности: надо чтобы глюк не был затёрт "байтом 0"
(
   Я-то разрушенный диск с ReFS сохранил.
   Надо же на чём-то тестировать утилиты.
)

--
} chkdsk
Да, эта утилита меняет данные зачастую и без ключа "исправить".
Чаще всего видел файлы нулевого размера.

P.S. ОЗУ хоть с ECC ?
Если без, то не битое?
P.P.S.
NTFS весьма надёжная FS.
При глобальных же сбоях - просто разворачивал последнюю ежечасную резервную копию.
Или реверсировал зеркало на Starwind HA.

Ответить | Правка | Наверх | Cообщить модератору

194. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (194), 20-Июн-23, 22:41

Бэкапа нет, как и диска чтобы его хранить. Я - админ локалхоста. Проблемный диск - самый большой в системе.

Ответить | Правка | Наверх | Cообщить модератору

236. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от pavlinux (ok), 24-Июн-23, 00:19

> ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по дефолту.
Ти кто, пилять, xyета Анонимная, советовать он может...  Тебе имя своё стадно писать.... аналлитики, йопт. Сцк.... ржууу  DDD

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

90. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Kuromi (ok), 19-Июн-23, 17:18

На самом деле на пользовательском уровне отличия очень даже очевидны. ext2 без журнала и может рассыпаться от неудачной пропажи жлектричества, ext3 медленная (по сравнению с ext2), дико долго удаляет файлы и fsck там нешустрый, в ext4 эти проблемы пофиксили, поэтому почти никакого резона сейчас использовать ext2\3 нет вообще.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

38. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (39), 19-Июн-23, 13:47

> По производительности Bcachefs опережает Btrfs и другие ФС на базе механизма Copy-on-Write, и демонстрирует скорость работы, близкую к Ext4 и XFS.
Ага, конечно, в перспективе разве что

Ответить | Правка | Наверх | Cообщить модератору

40. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (40), 19-Июн-23, 14:01

>Из планов на будущее упоминается желание использовать при разработке Bcachefs язык Rust. По мнению автора Bcachefs он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант. Rust уже задействован в Bcachefs в реализации некоторых утилит, запускаемых в пространстве пользователя. Более того, вынашивается идея постепенно полностью переписать Bcachefs на Rust, так как использование этого языка существенно экономит время на отладку.
супер, пройдет еще с десяток лет до принятия в ядро, пока он там все перепишет...

Ответить | Правка | Наверх | Cообщить модератору

54. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Анонус (?), 19-Июн-23, 14:49

Поэтому он сначала отправит в ядро, а потом начнет переписывать.

Ответить | Правка | Наверх | Cообщить модератору

78. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (6), 19-Июн-23, 15:52

Сначала его отправят как Шишкина, а потом он скажет что его притесняют.

Ответить | Правка | Наверх | Cообщить модератору

53. "Продвижение Bcachefs в состав ядра Linux" +3 +/–

Сообщение от pavlinux (ok), 19-Июн-23, 14:48

> надёжности и масштабируемости
Кэш - это временная свалка, для быстрого доступа.
Нахуа помойке снапшоты и резервное копирование? :D
Более того, порядок доступа, очередь к кэшу - это динамическое состояние.
Если после сбоя поднять сервер и востановить кэш из снапшота, то запрашивающие
клиенты уже ушли, нахер нужен снимок кэша часовой давности? ИТшные дол6оящеры.

Ответить | Правка | Наверх | Cообщить модератору

60. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от _hide_ (ok), 19-Июн-23, 15:00

Когда у тебя помойка под петабайт, а её сброс приведёт к отказу в обслуживании (реальное железо просто не выдаст нужно производительности для восстановления). Так что холодный старт как понятие отсутствует и кэш уже давно не кеш, а операционные данные, валидность которых проверяется как можно реже.

Ответить | Правка | Наверх | Cообщить модератору

87. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от n00by (ok), 19-Июн-23, 17:13

> Если после сбоя поднять сервер и востановить кэш из снапшота,
При записи на ФС данные идут на быстрый (твердотельный) накопитель, откуда фоном переносятся в хранилище (НЖМД). Первый в данном случае назван кешем. Восстанавливать его не от куда.

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

147. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Sw00p aka Jerom (?), 20-Июн-23, 08:47

DRAM->SSD->HDD

Ответить | Правка | Наверх | Cообщить модератору

56. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Unnamed Player (?), 19-Июн-23, 14:52

>В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.
Автор путает CoW и RoW?

Ответить | Правка | Наверх | Cообщить модератору

58. "Продвижение Bcachefs в состав ядра Linux" –1 +/–

Сообщение от pavlinux (ok), 19-Июн-23, 14:55

>>В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.
> Автор путает CoW и RoW?
А ты ешь ,кушаешь или жрёшь? :D

Ответить | Правка | Наверх | Cообщить модератору

61. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Unnamed Player (?), 19-Июн-23, 15:05

Реализация в корне отлична.

Ответить | Правка | Наверх | Cообщить модератору

70. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от pavlinux (ok), 19-Июн-23, 15:42

> Реализация в корне отлична.
CoW - это абстрактная хрень, нюансы зависят от авторов.
Кто-то FIFO называет CoW :)  C одного конца Copy, с другого Write

Ответить | Правка | Наверх | Cообщить модератору

202. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 21-Июн-23, 02:20

> CoW - это абстрактная хрень, нюансы зависят от авторов.
Однако у них есть и ряд типовых общих свойств. Например использование ресурса на хранение только дельты от оригигнала. И это хоть RCU vs RAM хоть qcow vs снапшот, хоть btrfs и reflink относительно оригинала. Эта идея останется во всех трех случаях, хоть детали реализации и драматически разные. Собственно это и есть пойнт для возни с такими технологиями. Оверсел и оверкомит ласкает слух. Иногда даже мне. Если я на 4-терабайтной хранилке разложил пяток "копий" 3-терабайтного образа в разных стадиях эксперимента по выуживанию из него данных  - я конечно "оверсельнул" себе 15 псевдо-терабайтов при всего 4 реальных, но это ж катит в силу природы файлов :)

Ответить | Правка | Наверх | Cообщить модератору

57. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (57), 19-Июн-23, 14:53

Чем отличается от lvmcache + ext4 ? Файловая система в курсе что кешировано, а что нет?

Ответить | Правка | Наверх | Cообщить модератору

203. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (-), 21-Июн-23, 02:20

> Чем отличается от lvmcache + ext4 ?
Нормальным менеджментом стоража в стиле btrfs вместо всей этой замшелой и кривой камасутры.

Ответить | Правка | Наверх | Cообщить модератору

64. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от keydon (ok), 19-Июн-23, 15:21

> Rust уже задействован в Bcachefs
> По мнению автора Bcachefs он любит программировать, а не отлаживать код,
Дальше не читал. Автор может и дальше пользоваться своей ФС. Еще одна недописанная и заброшенная в будущем ФС в ядре не нужна, тем более если тащит за собой раст.

Ответить | Правка | Наверх | Cообщить модератору

66. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноний (?), 19-Июн-23, 15:28

Спасибо, но я лучше reiser5 подожду.

Ответить | Правка | Наверх | Cообщить модератору

96. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (96), 19-Июн-23, 18:03

Кстати, а когда выйдет Ганс райзер? Я реально жду новый РайзерФС от ганса.

Ответить | Правка | Наверх | Cообщить модератору

100. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (100), 19-Июн-23, 19:53

Следующая попытка прошения помилования в 2026

Ответить | Правка | Наверх | Cообщить модератору

106. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (102), 19-Июн-23, 21:33

Ему же вроде в 23 должны были дать.

Ответить | Правка | Наверх | Cообщить модератору

107. "Продвижение Bcachefs в состав ядра Linux" –3 +/–

Сообщение от Аноним (102), 19-Июн-23, 21:45

Живым не выйдет. Он проявил гордыню, не продемонстрировал покорность, посмел отклонить первое предложение Суверена. Ну тогда до него довели, что чтобы его обвинить и казнить им железобетонных доказательств не надо, достаточно их личной убеждённости представителей Суверена, что это он сделал. Суверену нужно, чтобы все знали - с Сувереном шутки плохи.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

189. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 20-Июн-23, 20:18

Гордыня предшествует падению. Не зря так говорят.
Если с вами вообще тима работать совместно не хочет, и вы не понимаете что реюзабельные фичи надо вывешивать для всех caller'ов - кина не будет, тусите в своей пещере сами по себе. И вот сидит гражданин в своей пещере, сделав 0 доведенных до ума, юзабельных файлух. Рассказывает всем как надо было. Пруфом... ээ... сказки про белого бычка, отсыл к CS, сказ что я умный, все раки. А со стороны - очередной старый академбрюзга, бесполезный и не от мира сего.

Ответить | Правка | Наверх | Cообщить модератору

234. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (212), 22-Июн-23, 12:35

> И вот сидит гражданин в своей пещере, сделав 0 доведенных до ума, юзабельных файлух. Рассказывает всем как надо было.
а ты с ним сидел чтоли ?

Ответить | Правка | Наверх | Cообщить модератору

95. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от Аноним (96), 19-Июн-23, 18:02

>Из планов на будущее упоминается желание использовать при разработке Bcachefs язык Rust.
И этот вляпался.

Ответить | Правка | Наверх | Cообщить модератору

180. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Neon (??), 20-Июн-23, 19:04

Модно, стильно, молодежно))). Иначе грантик не дадут

Ответить | Правка | Наверх | Cообщить модератору

101. "Продвижение Bcachefs в состав ядра Linux" +1 +/–

Сообщение от fuggy (ok), 19-Июн-23, 21:19

Интересно что они там такое хотят блочное кешировать. Во-вторых, есть кеш ОС, если кеш самого диска, которым управляет контроллер диска. А тут целая ФС только для кеширования.
Сейчас большие HDD имеют кеш сравнимый с небольшим SSD. Ещё есть гибридные HDD, которые и являются по сути встроенный SSD для кеширования без всяких специальных ФС.

Ответить | Правка | Наверх | Cообщить модератору

108. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (104), 19-Июн-23, 21:51

> Сейчас большие HDD имеют кеш сравнимый с небольшим SSD. Ещё есть гибридные HDD, которые и являются по сути встроенный SSD для кешировани
При этом и те, и другие — консьюмерский отстой, которым большие операторы не пользуются.

Ответить | Правка | Наверх | Cообщить модератору

136. "Продвижение Bcachefs в состав ядра Linux" –2 +/–

Сообщение от Аноним (136), 20-Июн-23, 04:01

Сейчас уже и некоторые SSD с гигантским кэшем (на сотни гигов).
Вот только этот кэш сильно отличается и от кэша ОС и от кэша ФС в ОЗУ и управлять им условно не получится (в теории через отправку команд или изменение прошивки, на практике никак) и фактически считается характеристикой ssd и можно его даже и не рассматривать.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

210. "Продвижение Bcachefs в состав ядра Linux" +/–

Сообщение от bOOster (ok), 21-Июн-23, 08:46

И че толку от этого кэша если интерфейс по факту SAS/SATA?

Ответить | Правка | Наверх | Cообщить модератору

143. "Работа по включению Bcachefs в состав ядра Linux" –2 +/–

Сообщение от нах. (?), 20-Июн-23, 06:49

Что-то там включают-выключают в ядро, а может просто починить повышенную нагрузку на CPU при передвижении USB-Mouse? Да ну нет, бред какой-то. Сук, я 15 лет наблюдаю этот глюк, скажете виноваты иксы, а мне пох, мне пришлось купить мышку с PS/S, чтобы избавиться от этого, вот тебе и линукс.

Ответить | Правка | Наверх | Cообщить модератору

145. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от vbcnthfkmnth123 (ok), 20-Июн-23, 08:35

На Linux-libre этот глюк тоже наблюдается?

Ответить | Правка | Наверх | Cообщить модератору

148. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (148), 20-Июн-23, 09:33

Чего это она повышенная мышка же хорошо двигается, быстро. Почему бы не загрузить этим процессор. А то что там у аналоговых PS/2 что-то там меньше, так и двигается она хуже. Не так активно и самозабвенно.

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

181. "Работа по включению Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Neon (??), 20-Июн-23, 19:06

Это какой дохлый комп нужно иметь, чтобы USB-Mouse - давала повышенную нагрузку на CPU ?!))) На первопне что ли ? Или на 386 ?)))

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

144. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (144), 20-Июн-23, 07:43

> По мнению автора Bcachefs, он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант.
А по русски написать сложно было?

Ответить | Правка | Наверх | Cообщить модератору

149. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (148), 20-Июн-23, 09:33

Нажимай исправить и пиши, что сложно?

Ответить | Правка | Наверх | Cообщить модератору

150. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Пряник (?), 20-Июн-23, 09:54

> обновлённый набор патчей
Я, конечно, понимаю, что это скорее всего перевод, но этот акцент на обновлении патчей подразумевает, что все "в теме" и знают, что старая версия не зашла, а это обновлённая и уж точно всё будет гуд.
Либо текст реально достали из каких-то "внутренних" переписок.

Ответить | Правка | Наверх | Cообщить модератору

152. "Работа по включению Bcachefs в состав ядра Linux" +2 +/–

Сообщение от Пряник (?), 20-Июн-23, 10:19

Вот уже напрягает "стабилизация реализации снапшотов". Что там стабилизировать? Снапшоты должны просто работать, как в ZFS - снапшот это просто метаданные, то есть сохранённые адреса блоков ZFS. Даже на словах просто и понятно. Ломаться нечему, ZFS просто не подтвердит никакую запись данных в себе, пока корректно не считает записанный блок. А в этом Bcachefs какие-то "срезы" снапшотов.
Мне кажется разработкой заинтересуются, если она будет не маркетинговым описанием её крутизны, а простым и понятным всем механизмом, чтобы люди сами поняли, что это делает и нужно ли оно им.

Ответить | Правка | Наверх | Cообщить модератору

166. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 20-Июн-23, 16:06

> Вот уже напрягает "стабилизация реализации снапшотов". Что там стабилизировать?
_запись_
То, чего zfs не умеет в принципе, ее снапшот всегда readonly. А если тебе нужен записываемый но при этом ты не готов похоронить текущее состояние и нужно одновременно две ветки состояния фс параллельно - добро пожаловать в прекрасный мир клонов и букмарок. Полагаю большинство здешних фанатиков ими пользоваться не умеют.
Оно и действительно совершенно контринтуитивно.
В bcache по задумке все действительно красиво. Вопрос только в том, когда ж оно будет - работать.
И не попадем ли мы все в рай гораздо раньше.

Ответить | Правка | Наверх | Cообщить модератору

190. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (190), 20-Июн-23, 20:27

В btrfs оно тоже красиво и интуитивно. Большую часть дизайна Кент слизал оттуда, постаравшись обойти опробованные btrfs'ными лбами грабли. Нормальный подход так то.

Ответить | Правка | Наверх | Cообщить модератору

193. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 20-Июн-23, 22:35

> В btrfs оно тоже красиво и интуитивно.
вот вообще ни разу.

Ответить | Правка | Наверх | Cообщить модератору

204. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 21-Июн-23, 02:25

> вот вообще ни разу.
Да ну ладно тебе. Если виртуализатором с снапшотами хоть раз в жизни пользовался то и эти снапшоты в общем то логичны и понятны. А "one level above /" это так в моем стиле. Клево убунтуи это придумали.

Ответить | Правка | Наверх | Cообщить модератору

219. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 21-Июн-23, 13:24

хинт - не все виртуализаторы - бредовые поделки на базе все той же единственноверной фс.
А так у некоторых не будем покзаывать пальцем виртуализаторов все интуитивненько - "хотите вернуться на этот вот снапшот? Ок? Точно ок? Ваше текущее состояние и все вообще что вы с тех пор понаделали - сейчас превратится в тыкву!"
Что в целом вполне логично, где его хранить-то в системе где снапшот - сущность неизменная?
Нет, отдельно сохранить еще одно состояние конечно можно - но тут ты уже сам себе создаешь вермишель и сам как хочешь так и распутывай потом.

Ответить | Правка | Наверх | Cообщить модератору

229. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 22-Июн-23, 00:12

> же единственноверной фс.
Это о чем?! Я пользовался вмварью, гиперви, kvm... и в конечном итоге, логика CoW дисков-в-файле у них всех достаточно похожая. CoW диски-в-файле вообше ни на какой фс не основаны, они на блочном уровне работают как таковые.
...однако общая логика поведения снапшотов виртуалок - имеет довольно много общего. Особенно на тему отката состояния и отращивания альтернативного состояния из энной ключевой точки, оформленной как снапшот.
> состояние и все вообще что вы с тех пор понаделали -
> сейчас превратится в тыкву!"
Это вполне типовое поведение виртуализаторов: если надо текущее состояние сохранить - вон там создание снапошта. Иначе оно только подумайте - и правда продолбается после отката на вон тот снапшот. И так по-моему все вышеперечисленные работают. Их снапшоты аналогичны "read only" снапшотам btrfs. Writeable - возможность продолжить с этой точки и запомнить. По своему забавно - альтернативные истории растут под своими лэйблами.
> Что в целом вполне логично, где его хранить-то в системе где снапшот - сущность неизменная?
Большинство sci-fi где есть multiverse с разными вариантами развития событий и машины времени с тобой круто не согласны. В btrfs по-моему наиболее точная и полная реализация этого. И это круто. Можно завести несколько параллельных вселенных, похожих но разных, эволюционировать их, эти так, эти иначе, потом send вообще в вооон ту виртуалочку сделать, допустим - опа и это уже template для виртуалок вот такого типа. А вон то - эдакого. System integration @ level 80 это как-то так. ИМХО это в разы быстрее и круче всего что ты мог по теме.
> Нет, отдельно сохранить еще одно состояние конечно можно - но тут ты
> уже сам себе создаешь вермишель и сам как хочешь так и распутывай потом.
Снапшоты в btrfs могут быть как RW так и RO. Де факто пропертю RO на снапшот можно установить и снять постфактум и "обычными" методами они станут RO или RW - уж как хотелось. Это не только контролируемый time travel в мультивселенных - но и очень хорошо и гранулярно контролируемый, так что типовые траблы досаждавшие путешественникам во времени могут и не быть проблемой вот тут. Это по желанию.

Ответить | Правка | Наверх | Cообщить модератору

199. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от fidoman (ok), 21-Июн-23, 02:09

снепшоты это история fs, как может быть "интуитивной" запись в них?
может быть кому-то прикольно иметь автоклон для снепшотов - 2 в 1, унитаз с функцией биде, но не все оценят кмк

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

205. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (-), 21-Июн-23, 02:34

> снепшоты это история fs, как может быть "интуитивной" запись в них?
Если кто смотрел sci-fi и понял концепцию параллельных вселенных, похожих, но с разным развитием событий в каждой из них, а также путешествия во времени в ключевые точки где интересные разветвления случились, они давно понимают как это на самом деле работает... :)
> может быть кому-то прикольно иметь автоклон для снепшотов - 2 в 1,
> унитаз с функцией биде, но не все оценят кмк
Мультивселенную и машину времени для путешествия в ключевые точки (снапшоты) на самом деле. Это круче любого биде. Золоченый биде такая ерунда vs godlike powers, право...

Ответить | Правка | Наверх | Cообщить модератору

242. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от fidoman (ok), 07-Июл-23, 14:54

Удачи потом это мержить.

Ответить | Правка | Наверх | Cообщить модератору

211. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от bOOster (ok), 21-Июн-23, 08:51

Че за бред? Snapshot с записью? Отлично что ZFS проектировали не придурки, а люди четко представляющие смысл и цели решения...

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

230. "Работа по включению Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Аноним (-), 22-Июн-23, 00:25

> Че за бред? Snapshot с записью? Отлично что ZFS проектировали не придурки,
> а люди четко представляющие смысл и цели решения...
Btrfs умеет и readonly снапшоты, более того RO/RW снапшота можно менять через родной тул фс, изменением property у снапшота, если вдруг в энном случае передумали.
Как отсутствие выбора/фичи может быть фичой - я не допираю. Типа вы лучше меня знаете как мне снапшот хотелось? В любом случае, попробуйте FAT, там вообще фич нихрена, наверное это очень круто :)

Ответить | Правка | Наверх | Cообщить модератору

161. "Работа по включению Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Минона (ok), 20-Июн-23, 14:22

> вынашивается идея постепенно полностью переписать Bcachefs на Rust
Rust спасёт мир! ✌😤

Ответить | Правка | Наверх | Cообщить модератору

165. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от пох. (?), 20-Июн-23, 16:02

от bcachefs? Ну не факт. Пока это только идея, а в ведро того гляди уже включат.

Ответить | Правка | Наверх | Cообщить модератору

182. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Neon (??), 20-Июн-23, 19:07

Ага. Соберет всех неадекватов в одном месте)))

Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

213. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (212), 21-Июн-23, 11:35

> Rust спасёт мир!
из компилятора раст сделают SDK с ограничениями как для андроида и все формально открытые проекты где используется раст станут собственностью корпораций - никакой форк уже не спасёт

Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

216. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Минона (ok), 21-Июн-23, 12:38

> все формально открытые проекты где используется раст станут собственностью корпораций
Они и без раста собственность корпораций.

Ответить | Правка | Наверх | Cообщить модератору

218. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (212), 21-Июн-23, 12:52

> Они и без раста собственность корпораций.
нет, публикуя код в ядре ты не передаёшь права на него. Но что толку от такого кода если ты не сможешь использовать его в коммерчеком продукте без разрешения от правообладателя SDK раст чтобы его скомпилиовать.

Ответить | Правка | Наверх | Cообщить модератору

169. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от xsignal (ok), 20-Июн-23, 18:07

Растификация подсистем ядра. Начали с драйверов, теперь - ФС, потом - планировщик, система управления памятью, сетевая, и - оба на! - а ядро-то тю-тю - в руках растаманов, а те, кто стоял у истоков - уже и не при делах)

Ответить | Правка | Наверх | Cообщить модератору

208. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от pashev.ru (?), 21-Июн-23, 08:10

> По мнению автора Bcachefs он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант.
По мнению автора Bcachefs, который любит программировать, а не отлаживать код, было бы безумиеи писать код на языке Си теперь, после появления лучшего варианта.

Фух.... Отдебажил как смог.

Ответить | Правка | Наверх | Cообщить модератору

214. "Работа по включению Bcachefs в состав ядра Linux" +/–

Сообщение от Аноним (214), 21-Июн-23, 11:53

>Целью разработки Bcachefs является достижение уровня XFS в производительности
А достижения безгеморройности ext4 нет в планах?
Кстати, может, всё-таки Reiser4?

Ответить | Правка | Наверх | Cообщить модератору

217. "Работа по включению Bcachefs в состав ядра Linux" –1 +/–

Сообщение от Минона (ok), 21-Июн-23, 12:42

>>Целью разработки Bcachefs является достижение уровня XFS в производительности
> А достижения безгеморройности ext4 нет в планах?
Уверен что в ней нет геморроя?
> Кстати, может, всё-таки Reiser4?
А почему не 5?

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Скрыто модератором	–25 +/–
Сообщение от DEF (?), 19-Июн-23, 11:06
Пусть этот поц сначала нормальное название своей ФС даст. Да и зачем нужна эта поделка, если уже есть Btrfs?
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. Скрыто модератором	+8 +/–
	Сообщение от Аноним (2), 19-Июн-23, 11:09
	>уже есть что закапывать
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. Скрыто модератором	+12 +/–
	Сообщение от Аноним (3), 19-Июн-23, 11:10
	https://lore.kernel.org/linux-bcachefs/Yph4vK0KAjokd1UL@.../ Если кратко, то значительно более высокая производительность, поддержка кэширвоания на быстрых SSD и нормально работающие снапшоты.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	6. Скрыто модератором	+/–
	Сообщение от Аноним (6), 19-Июн-23, 11:23
	А если btrfs это все пофиксят в новых релизах зачем нужен bcachefs?
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	18. Скрыто модератором	+/–
	Сообщение от Аноним (6), 19-Июн-23, 12:09
	ASAP
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. Скрыто модератором	+3 +/–
	Сообщение от asdasd (?), 19-Июн-23, 12:50
	btrfs существует 14 лет, этот проект 10. У них все работает. Вопросы?
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	35. Скрыто модератором	–1 +/–
	Сообщение от Аноним (35), 19-Июн-23, 13:22
	всё работает? посмешил
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. Скрыто модератором	+2 +/–
	Сообщение от Аноним (77), 19-Июн-23, 15:51
	Написано "все", а не "всё".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	195. Скрыто модератором	+/–
	Сообщение от torvn77 (ok), 21-Июн-23, 00:30
	Работает то работает, но вот только в btrfs снапшот делается фиксацией содержимого файла и дозаписью изменений отдельно, что не требует создания отдельного архива, то в btrfs надо отправлять в буфер архив и хранить его отдельно, что что не только неудобно, но и приводит к избыточной пересылке информации.
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору


	81. Скрыто модератором	+/–
	Сообщение от n00by (ok), 19-Июн-23, 16:54
	В btrfs не пофиксят "поддержку кеширования на быстрых SSD", потому что там такого нет, надо использовать BCache.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	99. Скрыто модератором	–4 +/–
	Сообщение от DEF (?), 19-Июн-23, 19:30
	>Если кратко, то значительно более высокая производительность, поддержка кэширвоания на быстрых SSD и нормально работающие снапшоты. Это все есть в btrfs и снапшоты там работают отлично. Bcachefs (ппц, ну и название, назвал бы свою поделку BFS) - не нужна.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	113. Скрыто модератором	+/–
	Сообщение от Аноним (113), 19-Июн-23, 23:55
	> Это все есть в btrfs и снапшоты там работают отлично. Там есть 1 трабла: если на 1 экстент дофига референсов (например куча похожих снапшотов) - перфоманс может просесть. Это конечно специфичный случай но он есть. Дизайн bcachefs лучше адаптирован к такому случаю, "по итогам". Кент не будучи связан compat формата т.к. еще не в майнлайне - учел некоторые моменты. И по части перфоманса подрасперся конкретно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	132. Скрыто модератором	+/–
	Сообщение от DEF (?), 20-Июн-23, 02:02
	Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала без изменения формата Btrfs. Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и подводные камни, как только она станет популярной, как Btrfs.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	140. Скрыто модератором	+/–
	Сообщение от n00by (ok), 20-Июн-23, 05:59
	> Я готов решить эту проблему, > банально оптимизирую код > и перепишу некоторый функционал > без изменения формата Btrfs. Вот это здорово, все бы так. ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	170. Скрыто модератором	+/–
	Сообщение от Аноним (-), 20-Июн-23, 18:13
	> Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала > без изменения формата Btrfs. Не все известные проблемы решаются так. По итогам эксплуатации и выявленных проблем некоторые структуры сами разработчики btrfs'а делая это сегодня сделали бы уже иначе. В частности, если интересно, см их идеи на тему "extent tree v2" (нечто типа формата хранения v2). Оно даже где-то в работе, но поскольку там могут сменить формат несовместимо (в том смысле что "v1" драйвер на старых ядрах не сможет такое читать) - пользуясь случаем, вероятно, попробуют и еще ряд вещей починить. Так что это тоже не быстро будет наверное. А почему это надо? Оказалось что при массовой параллельной нагрузке и быстрых сторажах extent tree имеет недетскими проблемы с lock contention. Это убивает параллелизм операций и тормозит. Там, кстати, сбежаввший из редхата Басик как раз и зажигает :) При том как вы понимаете, никто не будет выбрасывать всю инфраструктуру драйвера и РАДИКАЛЬНО перепахивать формат. Заткнут очевидные проблемы наиболее простыми (по кодингу) способами. Что логично, не стоит сильно ломать активно эксплуатируемую кодовую базу. Кент же глядя на это все и будучи еще не замайнлайнен разумеется мог позволить себе редизайн некоторых вещей, даже если это и ломает совместимость - ему не с кем совместимость еще держать, так что может сделать "как лучше технически" раз 1 черт кодить от и до. В этом у него как у более позднего дизайна, совсем без требований совместимости, и ожиданий что это немедленно годно к эксплуатации - определенная фора. Пока еще может позволить себе достаточно резкие маневры если удачная идея пришла. > Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и > подводные камни, как только она станет популярной, как Btrfs. Несомненно при эксплуатации bcachefs вылезут какие-нибудь еще проблемы, которые сейчас тематические лица не предусмотрели, а тестирование новой кодовой базы с такими фичами и вышибание багов займет нехилое время. И возможно по итогам его эксплуатации кому-то захочется сделать другой дизайн, next gen next gen'а. Где устранят какие-то еще слабые места. Даже те о которых мы сейчас еще и не знаем. Это у шишкина все просто - развел теорий, практикой не проверял, и так то все ЗБС. А в реальном мире с реальными хотелками юзерей и реальными заскоками железа получается совсем не так как теоретические CSники себе это воображали, ну их барахло и работает совсем иначе чем они себе мнили в дофига случаев. По факту приходится делать странные костыли для затыкания порблем, пересматривать приоритеты, узнавать много нового об устройствах, их свойствах и отказах, и вообще сталкиваться с неидеальностью мира во весь рост. И без всего этого файлухи не особо нужны. Скажем "а что файлуха сделает на 1 бэд секторе". Или "а вот кернел ресетит девайс 2 минуты, это развал райда или нет? И если девайс вернется, то что?"
	Ответить \| Правка \| К родителю #132 \| Наверх \| Cообщить модератору


	126. Скрыто модератором	+1 +/–
	Сообщение от Аноним (126), 20-Июн-23, 00:49
	> назвал бы свою поделку BFS Название уже занято: https://en.wikipedia.org/wiki/Brain_Fuck_Scheduler
	Ответить \| Правка \| К родителю #99 \| Наверх \| Cообщить модератору


	129. Скрыто модератором	+/–
	Сообщение от DEF (?), 20-Июн-23, 01:55
	BCFS
	Ответить \| Правка \| Наверх \| Cообщить модератору


	160. Скрыто модератором	+/–
	Сообщение от Аноним (160), 20-Июн-23, 13:14
	Учитывая что та же красншляпа на БТРФС забила есть определенные сомнения что там что-то будут фиксить.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	162. Скрыто модератором	+/–
	Сообщение от Чукча (?), 20-Июн-23, 15:46
	Красношляпа стала панацеей? Может просто нежелание вкладываться в чужое достижение?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	179. Скрыто модератором	+/–
	Сообщение от Аноним (-), 20-Июн-23, 18:59
	> Учитывая что та же красншляпа на БТРФС забила есть определенные сомнения что > там что-то будут фиксить. На саму шляпу забили практически все известные по фс и блочному уровню ядерщики. Они и маются чем-то непонятным с пыхтонрасией в сратисе и гальванизацией XFS неизвестно зачем (точнее, известно, другого уже и не осталось - не jfs же им было брать?!). А вот Басик - вот тот самый, который раньше в редхате был - подсел на вот именно пиление именно бтрфс чего-то. Только теперь у него даже мыльник не редхатовский чего-то. А остальные из редхата и еще раньше слились.
	Ответить \| Правка \| К родителю #160 \| Наверх \| Cообщить модератору


	8. Скрыто модератором	+5 +/–
	Сообщение от Аноним (8), 19-Июн-23, 11:25
	Чем больше файлух, тем лучше. Конкуренция, все дела. Да и Шишкина позлить тоже приятно. Наверняка разродится еще одним "разгромным" интервью.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	52. Скрыто модератором	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 19-Июн-23, 14:46
	Что за разгромное интервью?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	94. Скрыто модератором	+1 +/–
	Сообщение от Аноним (94), 19-Июн-23, 17:43
	Да, кстати... Очень даже к месту! "Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято." https://habr.com/ru/articles/559014/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. Скрыто модератором	+/–
	Сообщение от Аноним (104), 19-Июн-23, 21:32
	Ну и как, трудоустроился Шишкин на ближайший десяток лет со своим поделием или пришлось на галеру идти?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	112. Скрыто модератором	+/–
	Сообщение от Аноним (112), 19-Июн-23, 23:50
	> Ну и как, трудоустроился Шишкин на ближайший десяток лет со своим поделием > или пришлось на галеру идти? Его величество развело кучу умствований и при том ... ВАУ - "ещё не определился с тем, как их реализовать для простых Reiser4 томов". Это он так про снапшоты. Поэтому я пока поюзаю на btrfs, со всеми его неидеальностями, зато - вот - с снапшотами. Которые может и не идеально, но - вот - работают. Потом может сабж попользуюсь, я надеюсь дожить до этого момента. А МакЛауды могут ждать когда его величество вообще осознает как к своему МегаИнновационному дизайну снапшоты вообще приделать. А сколько это накодить займет и тем более оттестировать до уровня стабильности не хуже хотя-бы btrfs вообще тактично помолчим - потому что люди столько не живут. Особенно если фича сразу не предусматривалась. Не та штука которую просто натянуть на глобус.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. Скрыто модератором	+2 +/–
	Сообщение от Аноним (-), 19-Июн-23, 23:21
	> Linux block layer с файловой системой (дурной пример заразителен). И что > характерно: там те же проблемы, что и в Btrfs. Это на самом деле очень крутой tradeoff. 1) Все операции с RAID уровнем значительно быстрее т.к. оперируют только занятым местом, а не всей площадью. 2) Это намного гибче в плане возможности воткнуть "уж какие есть" девайсы в пул. Без канифолинга мозгов выравниванием по размеру и потерь места на этой почве. Или даже вынуть девайс после временного расширения пула под разовую задачу. 3) У таких штук изумительная реконфигурация и даже смена схемы хранения. Это как пересесть из ржавого жигуля в маленький персональный звездолет. Теперь все не прибито на гвозди и можно выбирать масштаб и конкретику по ходу дела. И сменить например схему хранения если вон то - не нравится. 4) На это все снапшоты и дедуп ложатся явно лучше чем то что было до этого. И уж тем более лучше чем это работает на чистом блочном уровне. Btrfs создал новые паттерны по которым будут делать next-gen дизайны. Bcachefs продолжатель этого направления. Достаточно интересный. Сделанный с учетом проблем предшественников. И его кодер кажется может не только бла-бла на тему как надо, а конструктивную работу с апстримом на тему интеграции. В том числе и идти на компромиссы, и дорабаьывать core-подсистемы сообща. А не так что я тут отдельное нечто в своей норке, а ващи проблемы меня не волнуют, дескать.
	Ответить \| Правка \| К родителю #94 \| Наверх \| Cообщить модератору


	168. Скрыто модератором	+/–
	Сообщение от Аноним (94), 20-Июн-23, 17:28
	>1) Все операции с RAID уровнем значительно быстрее А циферки-то где? Быстрее чем тут? https://www.opennet.me/opennews/art.shtml?num=57026
	Ответить \| Правка \| Наверх \| Cообщить модератору


	171. Скрыто модератором	+/–
	Сообщение от Аноним (-), 20-Июн-23, 18:30
	> А циферки-то где? Быстрее чем тут? Циферки зависят от процента используемого места. Скажем если пул был на 10 терабайт, но реально пока используется только 100 гигов - при конверсиях, добавлениях и изъятиях устройств и т.п. ворочаться будут только те 100 гигов как максимум. Т.е. разница относительно обычного райда во времени операции будет в десятки раз. Одно дело глупым райдом по всей площади рестрайп делать, другое - удвинуть или сконвертить только реально используемые 10% емкости. И это сильный и валидный аргумент "за" управление томами из именно файлухи. Если из блочного уровня - он не файлуха, не знает что используется. Это обрекает пользователей на медленные и печальные операции "по всей площади" даже если использовалось 10% емкости. Попытки что-то сверх того делать выглядели еще более убого, криво и проблемно потому что блочный уровень начинает лезть в явно ФСовские епархии, для чего он не создавался. Файлухам это виднее. Наверное мог бы быть какой-то общий уровень абстракции для этого - но пока таких дизайнов мало, не очевидно как такое могло бы выглядеть. Должны появиться эн разных дизайнов чтобы понять что там общее в этом аспекте. А пока есть btrfs (zfs не в счет, он вообще не это) да вот bcachefs в виде злостного WIP. Не дофига данных для новых подсистем и рефакторов. > https://www.opennet.me/opennews/art.shtml?num=57026 Файлухи юзают не только ради циферок. И рейзер вообще умеет "space use aware" операции? Когда оно знает какой регион (не) используется и при конверсии схемы райд, изъятии девайса, уменьшении размера фс и проч - двигает только это? Кенту идея с backrefs и управлением пространством именно в контексте ФС тоже зашла и он тоже ее во многом содрал как я понимаю. Потому что это большой шаг вперед с точки зрения эксплуатации, что бы там шишкин не блеял. Подоткнуть первые попавшиеся девайсы для какого-нибудь разового расширения пула, а потом и быстро изъять эти девайсы бывает довольно круто. А шишкин такой номер вообще может показать для начала? Или у него только сказ про rampant layering violation? Это могут простить - если в замен предоставлены забойные фичи которыми обосновыается такая потеря эстетики и переизобретение колеса.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	191. Скрыто модератором	+/–
	Сообщение от Аноним (94), 20-Июн-23, 21:11
	> Циферки зависят от процента используемого места. Ну вот и поставь Btrfs в аналогичные условия. Создай том из нескольких дисков, на нём большой файл и замерь скорость удаления диска. > Файлухи юзают не только ради циферок От файлух требуется эффективно управлять дисковым пространством. То есть, компактно хранить данные и быстро проводить файловые операции, а также операции над томами. Остальное - это соревнования балерин по метанию молота. > И рейзер вообще умеет "space use aware" операции? Ненужно. См. выше.
	Ответить \| Правка \| Наверх \| Cообщить модератору