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

Продвижение 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]

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ообщить модератору

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

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