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

Продвижение Bcachefs в состав ядра Linux и переписывание на Rust, opennews (?), 19-Июн-23, (0) [смотреть все] Скрыто модератором, 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 4,5,9,11,14,27,32,36,38,40,53,56,57,64,66,95,101,143,144,150,152,161,169,208,214

Сообщения

[Сортировка по времени | 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.ru/opennews/art.shtml?num=57026
	Ответить | Правка | Наверх | Cообщить модератору

	171. Скрыто модератором	+/–
	Сообщение от Аноним (-), 20-Июн-23, 18:30
	> А циферки-то где? Быстрее чем тут? Циферки зависят от процента используемого места. Скажем если пул был на 10 терабайт, но реально пока используется только 100 гигов - при конверсиях, добавлениях и изъятиях устройств и т.п. ворочаться будут только те 100 гигов как максимум. Т.е. разница относительно обычного райда во времени операции будет в десятки раз. Одно дело глупым райдом по всей площади рестрайп делать, другое - удвинуть или сконвертить только реально используемые 10% емкости. И это сильный и валидный аргумент "за" управление томами из именно файлухи. Если из блочного уровня - он не файлуха, не знает что используется. Это обрекает пользователей на медленные и печальные операции "по всей площади" даже если использовалось 10% емкости. Попытки что-то сверх того делать выглядели еще более убого, криво и проблемно потому что блочный уровень начинает лезть в явно ФСовские епархии, для чего он не создавался. Файлухам это виднее. Наверное мог бы быть какой-то общий уровень абстракции для этого - но пока таких дизайнов мало, не очевидно как такое могло бы выглядеть. Должны появиться эн разных дизайнов чтобы понять что там общее в этом аспекте. А пока есть btrfs (zfs не в счет, он вообще не это) да вот bcachefs в виде злостного WIP. Не дофига данных для новых подсистем и рефакторов. > https://www.opennet.ru/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ообщить модератору

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

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