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

В ветку ядра Linux-next добавлена реализация ФС Bcachefs, opennews (??), 20-Сен-23, (0) [смотреть все] И ext4 хватает за глаза , Аноним (1), 08:36 , 20-Сен-23, (1) +9 // Да и 640кб хватит всем , Голум (?), 09:22 , 20-Сен-23, (4) +18 // Да Тогда чего ж у тебя место и память везде исчисляется в гб , Аноним (1), 10:41 , 20-Сен-23, (15) –10 // Да Тогда почему у тебя нет понимания что такое сарказм , Аноним (25), 11:30 , 20-Сен-23, (25) +16 Когда на сисблоке есть кнопка turbo и монитор всё ещё выпуклый - не до сарказм, коньюктивит (?), 13:53 , 20-Сен-23, (51) +5 А если к той кнопке подключить reset - вот тогда реально смешно , Аноним (85), 17:40 , 20-Сен-23, (85) +5 Трактор не нужен, 171 газельки 187 хватает за глаза , Аноним (8), 09:46 , 20-Сен-23, (8) –2 // Глупый человек всегда не понимает, как, что и с чем сравнивать , Аноним (1), 10:42 , 20-Сен-23, (16) –2 // Нет, глупый человек всегда обо всём судит категорично и исходит только из своих , Аноним (43), 13:05 , 20-Сен-23, (43) +3 в ext4 за глаза не зватает снапшотов аки ntfs Хотя, скоро можно будет и ntfs на, InuYasha (??), 10:27 , 20-Сен-23, (12) –4 // Если б за глаза не хватало, тогда была бы необходимость снапшоты нужны, но их ре, Аноним (1), 10:51 , 20-Сен-23, (17) +2 // На десктопах абсолютное большинство сидит на винде , Аноним (8), 10:56 , 20-Сен-23, (19) +6 Но, при этом, зачем-то ещё и здесь сидят , Аноним (53), 13:57 , 20-Сен-23, (53) +1 ну не у всех же хватает денег на лопатку на ведроиде, с единственноправильной ОС, пох. (?), 16:31 , 20-Сен-23, (78) С какой ОС , Аноним (88), 18:11 , 20-Сен-23, (88) Это не мешает миллиарду юзерей мордокниги юзать btrfs на его серваках , Аноним (-), 00:41 , 21-Сен-23, (129) Именно так, на серверах А на десктопах абсолютно неважно, на чём там сидят лину, Аноним (150), 08:35 , 21-Сен-23, (150) Тогда почему все линуксойдами становятся, сразу, как запускают броузер , EULA (?), 10:47 , 21-Сен-23, (159) Да И старый php в c компилить - предлагаешь всем на вооружение брать, раз САМ, User (??), 09:12 , 21-Сен-23, (151) btrfs значительно медленней ext4, btrfs при заполнении диска не может удалить фа, swarus (ok), 10:56 , 21-Сен-23, (160) Сильно зависит от ворклоадов При случае так cow и мастеркласс in place антика, Аноним (-), 15:42 , 21-Сен-23, (181) Спорно Зависит от диска HDD SDD , характера данных, настроек монитрования, тип, Аноним (184), 16:05 , 21-Сен-23, (184) –1 Тебе кто-то мозг разрушил Миллионы мух это вообще не показатель , Аноним (25), 11:43 , 20-Сен-23, (26) +1 а одна муха - показатель , Бывалый смузихлёб (?), 07:54 , 21-Сен-23, (145) +1 Один сердитый шмель вполне может преподать тебе урок , Аноним (184), 16:09 , 21-Сен-23, (185) Шмели никак не касаются мух И живут в земле, реально в земляных норахЛадно бы о, Бывалый смузихлёб (?), 17:25 , 22-Сен-23, (248) А вот и демократия подъехала Большинство людей не пользовались туалетной бумаго, keydon (ok), 12:06 , 20-Сен-23, (35) +3 А вы же написали это как сарказм , коньюктивит (?), 13:56 , 20-Сен-23, (52) Надеюсь что это все очевидно, keydon (ok), 16:33 , 20-Сен-23, (79) Но, на самом деле, она безопасТная , Аноним (53), 13:59 , 20-Сен-23, (54) Ну, не знаю Андроид - основная операционная система, которую я использую Мне в, коньюктивит (?), 16:45 , 20-Сен-23, (80) Именно такое впечатление она, вроде, и должна производить , YetAnotherOnanym (ok), 17:00 , 20-Сен-23, (83) Да зашибись просто Рекламой - смердит, данные - сливает, пароли от точек доступ, Аноним (107), 22:11 , 20-Сен-23, (107) Где реклама В гугл плей реклама вот прямо сейчас зашёл и нет там её Сливает , коньюктивит (?), 23:52 , 20-Сен-23, (114) Как нет А в верху самом это не реклама, типа Да и если софт поставить - особен, Аноним (-), 00:38 , 21-Сен-23, (128) +1 В бесплатных приложениях, напримерСамое забавное, что с некоторых пор гугел прак, Бывалый смузихлёб (?), 07:58 , 21-Сен-23, (146) нельзя владелец кода занят обустройством личной жизни в Германии, ему не до бес, пох. (?), 11:53 , 20-Сен-23, (30) –3 // Последний писк технологий девяностых С эрзац-подобием снапшотов ставящий колом , Аноним (-), 23:27 , 20-Сен-23, (109) +1 в ext3 4 есть снапшоты - но этот код не был принят в основную ветку ядра Последн, Аноним (73), 15:27 , 20-Сен-23, (73) // ссылки, явки, пароли , Аноним (88), 18:13 , 20-Сен-23, (89) https www opennet ru opennews art shtml num 30826, maximnik0 (?), 21:30 , 21-Сен-23, (219) просвети тёмных, ссылку дай снапшоты нафиг сдались для меня , а вот ограничения, swarus (ok), 11:04 , 21-Сен-23, (161) Скрыто модератором, ivan_erohin (?), 23:43 , 21-Сен-23, (227) Сравнивать эти костяшки с сабжем - как сравнивать конную тягу с скоростным поезд, Аноним (107), 22:08 , 20-Сен-23, (103) ntfs медленнее ext4 на 25 , swarus (ok), 10:42 , 21-Сен-23, (158) // Даже в ядре Я готов на 20 лишь бы иметь общую нормальную ФС, поддерживаемую вс, InuYasha (??), 22:19 , 23-Сен-23, (271) Зато если под системной либой случайный бэд образуется - глаза получаются доволь, Аноним (-), 22:05 , 20-Сен-23, (102) // О чем ты Расскажи подробнее, Вопрос (?), 01:26 , 21-Сен-23, (131) // 1 В btrfs можно даже на 1 устройстве разложить данные в схему хранения DUP А м, Аноним (-), 02:35 , 21-Сен-23, (138) +1 Под винду и на подобные случаи были штуки вроде WinHexВ былые времена позволявши, Бывалый смузихлёб (?), 08:07 , 21-Сен-23, (147) // Это антипод вон тех техноолгий Там видите ли рояль в кустах разложен так чтобы , Аноним (183), 16:04 , 21-Сен-23, (183) В смысле без шансов , AlexYeCu_not_logged (?), 15:23 , 21-Сен-23, (178) // В самом простом У меня на EXT4 разок вылез редкий, меткий, мерзкий бэд аж под l, Аноним (186), 16:26 , 21-Сен-23, (186) ext4 нормально фурычил на хреновых hdd бэд переводил в read-only режим, отмонтир, swarus (ok), 23:33 , 26-Окт-23, (298) Тебе на твоём localhost хватит и windows 98 с fat32 , Аноним (231), 02:43 , 22-Сен-23, (231) +1 Уровень XFS недостижим , Аноним (2), 08:36 , 20-Сен-23, (2) –1 // Было бы чего достигать Отрицательного ресайза нет, аккуратного использования ди, Аноним (53), 14:01 , 20-Сен-23, (56) // Как только напишешь непротиворечивый алгоритм 171 отрицательного ресайза 187 , Менеджер Антона Алексеевича (?), 17:04 , 20-Сен-23, (84) // Скрыто модератором, Аноним (-), 19:06 , 20-Сен-23, (92) В btrfs накодили - сделали backrefs которые указывают кому блок принадлежит При, Аноним (-), 23:46 , 20-Сен-23, (113) +1 И не один Дьявол в деталях Как это всё по-твоему должно работать когда на ФС а, Менеджер Антона Алексеевича (?), 17:24 , 21-Сен-23, (196) Элементарно, Ватсон 1 Избегаем записей в регион интереса 2 Расчищаем его в фон, Аноним (-), 18:40 , 21-Сен-23, (203) +1 Так BTRFS и ZFS уже есть, туда кодить не надо, там всё уже работает Если ты пос, Менеджер Антона Алексеевича (?), 00:57 , 22-Сен-23, (228) лолшта zfs научилась уменьшать размер пула А пацаны-то и не знают Все что он, пох. (?), 08:54 , 22-Сен-23, (236) Выкидывание устройства из рейда действительно феерично бесполезная фича У меня , Менеджер Антона Алексеевича (?), 17:04 , 22-Сен-23, (247) Мне вот это было полезно для примерно такого Датарекавери с большого диска Мож, Аноним (-), 17:32 , 22-Сен-23, (250) Именно И поскольку Линукс пишется корпорациями для своих корпоративных нужд, ло, Менеджер Антона Алексеевича (?), 18:17 , 22-Сен-23, (252) нормальные люди уходят в винду, которую корпорация пишет - для людей Именно так, пох. (?), 19:36 , 22-Сен-23, (254) Ога, нормальные потребители и хомяки Ну, может, очень узкоспециализированные ли, Аноним (-), 00:37 , 23-Сен-23, (259) Ну как бы я с своими кейсами довольно неплохо вписываюсь в это все Например, па, Аноним (-), 00:33 , 23-Сен-23, (258) там нельзя выкинуть даже целиком вдев с рейдом заколдованные оне большие сторад, пох. (?), 19:30 , 22-Сен-23, (253) Ну, кроме локалхоста есть и смежные применения Кастомдев там всякий и проч, ког, Аноним (260), 00:41 , 23-Сен-23, (260) Вы спросили какой _алгоритм_ этого действа Я и обрисовал вполне валидный и рабо, Аноним (-), 17:25 , 22-Сен-23, (249) Это какой-такой уровень Разрешать каждой программе пихать свои васяноатрибуты н, Аноним (99), 20:50 , 20-Сен-23, (99) +1 // Поддержка атрибутов - необходимое требование для UNIX FS И по умолчанию, без за, Аноним (175), 14:44 , 21-Сен-23, (175) Майнтайнер оного тоже так подумал - и съ ся восвояси от греха подальше, когда , Аноним (-), 23:30 , 20-Сен-23, (110) Так это же она 8212 новейшая революционная единая файловая система для всего , Аноним (5), 09:26 , 20-Сен-23, (5) +2 // Сказал как старый коммунист Молодой бы сказал на твоём месте - серебрянная пул, Аноним (7), 09:44 , 20-Сен-23, (7) –2 // стеклянный, деревянный, оловянныйсеребряный, Анонизмус (?), 09:50 , 20-Сен-23, (9) +10 // Посеребренная, Аноним (18), 10:51 , 20-Сен-23, (18) –1 гугли разницу между отглагольными прилагательными и причастиями, а лучше в школу, 12yoexpert (ok), 14:03 , 20-Сен-23, (58) Ну да, серебрянная, сделанная в Китае , Аноним (53), 14:03 , 20-Сен-23, (60) –1 Повеяло чем-то тёплым и ламповым Ещё бы напомнили о 171 раненом 187 и 171, Аноним (97), 20:41 , 20-Сен-23, (97) Стрелой в колено же , коньюктивит (?), 23:55 , 20-Сен-23, (117) и уж замуж невтерпёж , Аноним (97), 20:43 , 20-Сен-23, (98) +1 Хороший ориентир, и цели хорошие ага, главное не забыть запилить фичу порчи файл, Аноним (10), 10:15 , 20-Сен-23, (10) // Ты из 2010 , fumanchez (ok), 11:17 , 20-Сен-23, (22) +4 // нет, он гораздо ранешний попаданец - даже в 2010м уже умели фичу порчи файлов бе, пох. (?), 11:54 , 20-Сен-23, (31) +9 РАО ЕЭС закончилось в 2008 , Аноним (53), 14:05 , 20-Сен-23, (62) // 8230 И качество электроснабжения изменилось кардинально, ага , Аноним (8), 14:43 , 20-Сен-23, (67) +1 Вот чего нет 8212 того нет , Аноним (81), 16:53 , 20-Сен-23, (81) +1 // Дурачек всегда думает - если его проблема не коснулась, то и проблемы нет , bOOster (ok), 11:04 , 25-Сен-23, (283) Это при недостатке фич или пропорционально количеству граблей , Аноним (11), 10:27 , 20-Сен-23, (11) // Как я понимаю при меньшем количестве факапов и проблем и лицензиями , Аноним (44), 13:06 , 20-Сен-23, (44) +1 // Это не так работает, попробуй ещё раз, Аноним (11), 22:10 , 20-Сен-23, (105) А когда будет Ext5 уже где всё это из коробки , Аноним (11), 10:27 , 20-Сен-23, (13) // Вот только в ext это всё пихать не надо , Аноним (8), 10:56 , 20-Сен-23, (20) +2 // Надо Ты скучный, Аноним (11), 22:11 , 20-Сен-23, (106) –2 А как переименуют сабжа так и будет EXTn - всегда делался на основе легаси диза, Аноним (-), 23:32 , 20-Сен-23, (111) // Большинству людей того Ножками за хлебушком через день ходить, а им каждый ра, User (??), 09:20 , 21-Сен-23, (152) +3 // Никому не интересно на каком лисапеде ты дома от мамки гоняешь, у дядечек петаба, Аноним (11), 13:14 , 21-Сен-23, (165) –2 главное - веровать Что есть мудрые дядечки у которых таааакие приборы мы за га, пох. (?), 17:11 , 21-Сен-23, (193) +1 А на чём там сейчас петабайты у дядек А то я давно не интересовался Развели вс, InuYasha (??), 19:43 , 23-Сен-23, (269) ну вот тебе показательная история отрицательного успеха не нашего https li, пох. (?), 09:21 , 26-Сен-23, (289) I m lovin it , InuYasha (??), 10:40 , 27-Сен-23, (293) Можно пойти дальше, треть россиян вообще в позе орла нужду справляет до сих пор , Аноним (187), 16:40 , 21-Сен-23, (187) Ну да А у нехомяков появилась ещё одна замечательная уже почти-но-ещё-не-совсем, User (??), 16:56 , 21-Сен-23, (189) Я совсем не возражаю если вы будете упражняться в тао фигачения по конским бокам, Аноним (-), 17:40 , 21-Сен-23, (199) А другие это какие У ZFS RoW, Аноним (11), 10:28 , 20-Сен-23, (14) // У ZFS - CoW , Минона (ok), 15:23 , 20-Сен-23, (72) +1 // Нет, Аноним (11), 22:10 , 20-Сен-23, (104) // Да RTFM , Минона (ok), 10:21 , 21-Сен-23, (157) Нет, кури мануалы поактуальнее, Аноним (11), 13:15 , 21-Сен-23, (166) Угощай, покурим , Минона (ok), 21:17 , 21-Сен-23, (218) В ветку ядра Linux-next добавлена реализация ФС Bcachefs, kvaps (ok), 17:55 , 21-Сен-23, (201) // Теже яйца, только в профиль , bOOster (ok), 11:07 , 25-Сен-23, (284) Опять велосипеды вместо того, чтобы использовать lvm2 Ну откуда они такие лезут, Аноним (21), 11:10 , 20-Сен-23, (21) // зачем лишняя прослойка, когда можно без лишней прослойки башкой думай иногда, Аноним (23), 11:18 , 20-Сен-23, (23) // Сходи к программерам - вот где прослоек 8230 LVM - рабочая, но еЯ IBM ещё в 19, _ (??), 11:52 , 20-Сен-23, (29) Не делай слишком маленькие экстенты и не заметишь её существования Оптимально, , Аноним (53), 14:09 , 20-Сен-23, (63) –2 Не лишняя, котлеты отдельно, мухи отдельно А когда намешано в одну кучу, то это, microcoder (ok), 20:00 , 20-Сен-23, (94) +1 // Ну, понимаешь, в btrfs в результате можно btrfs device add на вооон тот наобум, Аноним (-), 00:28 , 21-Сен-23, (127) +2 вы прослушали рассказ о том, как страшна и безблагодатна жизнь пользователей, User (??), 09:24 , 21-Сен-23, (153) –1 В LVM тоже самое делается, только безопасней на мой взгляд У тебя атомарная ф, microcoder (ok), 14:50 , 21-Сен-23, (177) –1 на твой безграмотный взгляд И дело не в на одну команду больше, а в том что у те, пох. (?), 16:56 , 21-Сен-23, (188) Ну а и btrfs интегрированность cow знание аллокации таки дает все знания котор, Аноним (-), 17:23 , 21-Сен-23, (195) если б еще и работало - но raid6 пишутъ что в общем-то как бы и намекает на, пох. (?), 17:31 , 21-Сен-23, (197) Дык работает А RAID56 как бы явно маркированы как экспериментальные Таки не ви, Аноним (-), 18:01 , 21-Сен-23, (202) Вот только не нужно говорить так, как будто это что-то хорошее В отсталыхгосудар, Аноним (81), 16:58 , 21-Сен-23, (190) Btrfs на поверку переживает крах и ребут даже при конверсии схемы RAID, на минут, Аноним (183), 17:14 , 21-Сен-23, (194) Пробовал летать на самолёте отдельно без крыльев, кабины и двигателя , Пряник (?), 14:36 , 21-Сен-23, (170) Всё летает, LVM отдельно, FS отдельно Ноу проблем , microcoder (ok), 14:38 , 21-Сен-23, (172) +1 Вас наели, это не самолет, это жигуль ржавый А летит он и правда без двигателя , Аноним (-), 21:08 , 21-Сен-23, (216) Да нет - это у вас крылья лежат в салоне самолёта и пассажиры ими машут Файлы пу, InuYasha (??), 19:52 , 23-Сен-23, (270) Да нет, чувак, тот то читер имел весьма годный план врубив гипердрайв он проско, Аноним (-), 05:57 , 24-Сен-23, (272) Коробка новых однотипных хардов в шкафу, Парагон и Акронис, телефон службы рекав, InuYasha (??), 10:14 , 24-Сен-23, (273) Ну да, ну да, видал я это все Проблема в том что все это д рьмо не может в резу, Аноним (-), 16:32 , 24-Сен-23, (276) Так весь твой хвалебный опус про что в итоге был - про bcachefs или btrfs От бэд, InuYasha (??), 21:21 , 24-Сен-23, (277) Пока - про btrfs Сабж рановато в активную эксплуатацию Но как дизайн он мне ве, Аноним (-), 00:31 , 25-Сен-23, (281) Ну если слаще морковки ничего и не пробовал 8230 то можно и LVM2 Оно в принц, _ (??), 11:47 , 20-Сен-23, (28) // по началу - как раз нет, все работает из коробки и сразу Вот при продолжении на, пох. (?), 11:55 , 20-Сен-23, (32) Одна большая помойка Лучше котлеты отдельно, мухи отдельно Не надо в файловую , microcoder (ok), 20:03 , 20-Сен-23, (95) // К сожалению LVM копирует оригинальные данные в снапшот при изменении Copy-on-Wr, Пряник (?), 14:43 , 21-Сен-23, (174) В thin lvm это уже не так, но связываться с ним - такое себе , пох. (?), 17:07 , 21-Сен-23, (192) Такое впечатление, что это ты кроме морковки ничего не едал Постоянно про морко, Аноним (179), 15:35 , 21-Сен-23, (179) Слишком сложно Используй EXT2 и не беспокойся этих глупостев 8482 , Аноним (81), 16:54 , 20-Сен-23, (82) // Во Апдейт сломал систему Выключаешь компу питание и перезапускаешь в состоянии, Аноним (99), 21:00 , 20-Сен-23, (100) // Апдейт выполняется в авторизованной мастерской квалифицированным персоналом Сам , Аноним (81), 17:00 , 21-Сен-23, (191) Да вот видишь ли, хотят люди нормальное управление файлухами И впном - вайргад,, Аноним (-), 23:37 , 20-Сен-23, (112) –1 // Wireguard - это не VPN, а кастрат , Аноним (130), 01:00 , 21-Сен-23, (130) // То ли дело IPSec, уровень на уровне и уровнем погоняет - и когда вы фигурно потр, Аноним (-), 01:48 , 21-Сен-23, (135) –1 очередной свидетель ужасов ipsec, видевший его только во сне наши 4000 смотрят , пох. (?), 07:45 , 21-Сен-23, (143) Ты как минимум в чем-то прав Например, я предпочел забыть такие технологии как , Аноним (-), 19:06 , 21-Сен-23, (204) –2 забыть то о чем никогда ни малейшего представления не имел Ну да Уровень мес, пох. (?), 20:54 , 21-Сен-23, (214) +1 Да вот к сожалению пришлось немного познакомиться Откуда и узнал что знатный пр, Аноним (-), 21:16 , 21-Сен-23, (217) –2 Еще один свидетель RUSTовый Нах на вы лезете туда, разбираться в чем не хоти, bOOster (ok), 11:24 , 25-Сен-23, (285) ИМХО, дискредитируют - напыщенные бакланы, которые свое мнение обосновать не спо, Аноним (-), 15:25 , 26-Сен-23, (290) –1 Не используй винду - не надо будет в реестре ковыряться , tipa_admin (?), 11:56 , 21-Сен-23, (163) –1 Вот ни разу не видал людей, которые хотели бы wireguard - обычно у всех хотели , User (??), 09:32 , 21-Сен-23, (154) // ну тут есть нюанс - оно может и работает - только не всегда и не у всех Впрочем,, пох. (?), 10:03 , 21-Сен-23, (156) Ну вот sstp от ms скорее работает Anyconnect от Cisco - скорее да Даже какой, User (??), 14:38 , 21-Сен-23, (171) А что не так с WG на любой актуальной ОС Кажется везде кроме форток он уже чуть, Аноним (11), 13:17 , 21-Сен-23, (167) Нукакгбэ да - но у 97 людей возможны варианты , User (??), 14:39 , 21-Сен-23, (173) +1 Вот ни разу не видал людей, которые хотели бы wireguard - обычно у всех хотели , User (??), 09:38 , 21-Сен-23, (155) IPSec как раз таки и является самым нормальным VPN Точнее IPSec это лишь шифров, Пряник (?), 14:47 , 21-Сен-23, (176) –1 // ipsec это и есть vpn Вполне образует эту самую virtual network произвольной топ, пох. (?), 21:01 , 21-Сен-23, (215) У IPSec два режима транспортный и туннельный В транспортном шифруется только с, Пряник (?), 10:20 , 22-Сен-23, (237) –1 Для меня лично теперь основной критерий выбора - поддержки сжатия на уровне фс , fumanchez (ok), 11:22 , 20-Сен-23, (24) –1 // NTFS, уже почти тридцать лет , Аноним (8), 11:46 , 20-Сен-23, (27) // лол было бы чем гордиться, сжатие работает лишь для кластеров 4кну и бонусом и, Ананий (?), 12:23 , 20-Сен-23, (37) // Даже не вспомню, когда я видел NTFS с размером кластера, отличным от 4К , Аноним (8), 12:41 , 20-Сен-23, (40) На диске С кстати когда уже этот анохронизм сподобятся убрать или так и будем, Ананий (?), 12:52 , 20-Сен-23, (41) –1 Давай посмотрим на вопрос под другим углом много ли кто при создании NTFS-разде, Аноним (8), 13:01 , 20-Сен-23, (42) +2 Многие - те самые владельцы современных дисков по 20 тер c 4 лимит 16, но устан, пох. (?), 13:22 , 20-Сен-23, (45) ну так еще и не зашифровать самым лучшим на свете тм битлокером , Ананий (?), 13:27 , 20-Сен-23, (47) 20T Мгм Др-чи что-ли в разрешении поменьше ну или хотя бы на разрешенный, пох. (?), 13:39 , 20-Сен-23, (49) Меньше скорость чтения записи, особенно для нжмд, разрастание двух MFTВпрочем о , Ананий (?), 13:25 , 20-Сен-23, (46) Скорость чтения записи стогигабайтных файлов ограничивается исключительно носите, Аноним (8), 13:36 , 20-Сен-23, (48) +1 И ещё один анахронизм заголовок MZ у файлов формата PE, заодно и расширение ех, Аноним (53), 14:19 , 20-Сен-23, (64) Можно в com переименовать для разнообразия Раньше ещё сигнатура ZM вместо MZ ра, Аноним (8), 14:54 , 20-Сен-23, (68) Скрыто модератором, Аноним (-), 19:08 , 20-Сен-23, (93) Они это даже в UEFI затолкали И вот этот гуашь уже и дос то загружать в части р, Аноним (-), 23:54 , 20-Сен-23, (116) Ну если вы найдёте MS-DOS под ARM 8230 , Аноним (150), 08:33 , 21-Сен-23, (149) тооочна При ширпотребных дисках по 20 терабайт и nvme модулях работающих уже по, пох. (?), 11:56 , 20-Сен-23, (33) +2 // Разница в пропускной способности на порядок, в лучшем случае это если PCIe 5 0 , Аноним (36), 12:08 , 20-Сен-23, (36) +2 // Во сколько раз сжимаются документы, раз в 10 Ну будет у тебя отчёт открываться з, Минона (ok), 14:26 , 20-Сен-23, (65) +1 Увеличение ЧСВ на порядок , 1 (??), 16:20 , 20-Сен-23, (75) +1 В первую очередь я выиграю место на диске, и уже одного этого мне будет достаточ, Аноним (36), 16:22 , 20-Сен-23, (76) Эм, смотря какие Если docx - то не восколько, они уже пожаты А если кто-то чег, User (??), 23:57 , 20-Сен-23, (118) Да вот видите ли - он выиграть может 1 Доступное свободное место А поди плох, Аноним (-), 23:57 , 20-Сен-23, (119) +1 У меня хомяк похудел почти на треть с zstd при самой легкой степени сжатия, а та, fumanchez (ok), 01:40 , 21-Сен-23, (133) +1 А у меня система и ее снапшоты раза в 2 с гаком полегчали на SSDшнике Поди п, Аноним (-), 01:55 , 21-Сен-23, (136) +1 просто пофигу Никому в 2k23 неинтересно занимает ли твоя система вместе с нен, пох. (?), 07:41 , 21-Сен-23, (142) Скрыто модератором, Аноним (-), 19:11 , 21-Сен-23, (205) –2 Я до слёз от мысли как ты будешь файлы каким-нибудь O O recovery по заголовкам и, InuYasha (??), 10:18 , 24-Сен-23, (274) Был бы умный - знал бы, что жмется не все подряд , fumanchez (ok), 10:54 , 24-Сен-23, (275) И что же Как, интересно, фс узнает, что у BMP-файла есть заголовки, а внутри чт, InuYasha (??), 21:23 , 24-Сен-23, (278) Если тебе лень открывать документацию, то кратко btrfs пытается сжать первые 12, fumanchez (ok), 00:08 , 25-Сен-23, (280) Ну, это уже прямое нарушение OSI ФС вообще сжатием заниматься не должна Решени, InuYasha (??), 11:05 , 27-Сен-23, (294) ФС может хранить данные вообще как угодно, и решение таки принимает юзер - сжати, fumanchez (ok), 12:26 , 27-Сен-23, (295) сколько его вообще похрен всем Неплохо если терабайт подешевеет - но откуда у н, пох. (?), 07:26 , 21-Сен-23, (141) +1 А где как На системных SSDшниках места не так уж и дохрена, оно денег сотит, а , Аноним (-), 19:21 , 21-Сен-23, (207) страдания долбанавтов держащих какой-то ненужный мусор в системном разделе вмест, пох. (?), 20:23 , 21-Сен-23, (211) Я уже понял что твой потолок использования компьютеров - это хомячить А софт ви, Аноним (220), 21:35 , 21-Сен-23, (220) Полный бред, как про объемы, которые составляют 1-2 ТБ для HDD и 256 ГБ для SSD, fumanchez (ok), 01:28 , 21-Сен-23, (132) // у тебя криокамера потекла С разморозочкой, но тебе у нас не понравится Чини бы, пох. (?), 07:22 , 21-Сен-23, (140) Ок, ширпотребный НОВЫЙ хард на текущий момент это 8ГБ для ПК и 2 ГБ для ноутов, , fumanchez (ok), 12:16 , 21-Сен-23, (164) дружище, не все живут в помойном бачке Первые результаты тебе видимо показывают, пох. (?), 15:42 , 21-Сен-23, (180) Вот прям ГБ Путешественник во времени не палится А поэтому дома у него будет , Аноним (-), 19:24 , 21-Сен-23, (208) если по цене отсортировать то могут и дискеты вылезти Пятидюймовые да-да коне, пох. (?), 20:31 , 21-Сен-23, (212) Эм, ну я бы взял себе несколько штук для антуражу И винчей и дискет Если по бр, Аноним (-), 21:49 , 21-Сен-23, (221) А ты в курсе что ход дисков менее 100 гиг больше даже не продаётся Зойчем сжима, _ (??), 11:56 , 20-Сен-23, (34) –1 Ура Очередной бтрфс завезли На ближайшие 10 лет разработчикам файловых систем , Аноним (50), 13:47 , 20-Сен-23, (50) +1 // Люди сидят на cow, на ехт4 сидит масса, Самый умный из вас (?), 16:23 , 20-Сен-23, (77) // Сидят на корове Они не знают, что корова не ездовое животное Ох уж эти маргина, коньюктивит (?), 23:58 , 20-Сен-23, (120) // apt moo, Аноним (11), 13:19 , 21-Сен-23, (168) +1 Ну так до сих пор вон чувак с деревянной телегой в правом ряду тошнится Если от, Аноним (-), 00:00 , 21-Сен-23, (122) // То ли дело ты - на феррари с хомяком в колесе вместо двс Ачо, всё равно только , Аноним (255), 21:10 , 22-Сен-23, (255) // Я уже давно не езжу Я навигирую по 4-мерному пространству, в чем-то типа гибрид, Аноним (-), 00:58 , 23-Сен-23, (261) Навигируешь на виртуальной машине, получается D, InuYasha (??), 21:25 , 24-Сен-23, (279) Менеджмент большей части моих железок мало чем отличается от виртуалок, сюрприз , Аноним (-), 02:04 , 25-Сен-23, (282) что такое ФС FS , 12yoexpert (ok), 13:59 , 20-Сен-23, (55) –2 // Да, Failovaya Sistema , Аноним (8), 14:03 , 20-Сен-23, (61) +9 // Da, Fail System , InuYasha (??), 20:17 , 20-Сен-23, (96) +3 В Bcachefs используется механизм Copy-on-Write COW , при котором изменения не , Аноним (66), 14:34 , 20-Сен-23, (66) –1 // Нет, это CoW Отличия смотри тут https support huawei com enterprise ru doc ED, Минона (ok), 15:22 , 20-Сен-23, (71) // по описанию в новости- ROW, а чо там внутри я без понятия , Аноним (90), 18:34 , 20-Сен-23, (90) У этой технологии много имен Примерно то же по смыслу для памяти называется RCU, Аноним (-), 00:05 , 21-Сен-23, (123) Очередная SSD-ориентированная и еще NOVA на подходе Притом что когда появилас, Kuromi (ok), 16:16 , 20-Сен-23, (74) // Оно не SSD ориентированное а универсальное и многодевайсное Все новые дизай, Аноним (126), 00:15 , 21-Сен-23, (126) +2 // На самом деле он уже несколько лет как многодевайсный, при создании ФС и позже , Kuromi (ok), 22:12 , 21-Сен-23, (225) // О, и правда завезли Но ты уж извини, там про лишь рассмотрение как 1 большого д, Аноним (-), 01:46 , 22-Сен-23, (229) Да, у F2FS вообще нет никакиого намека на менеджмент томов, там просто объединяю, Kuromi (ok), 13:01 , 22-Сен-23, (239) Ответ ради ответа А смысл Аналог этого сто лет можно было lvm md dm и ко дюжин, Аноним (-), 18:15 , 22-Сен-23, (251) +1 Кстати многопоточность в F2FS была всегда По умолчанию она пишет на диск в 4 к, Kuromi (ok), 13:52 , 22-Сен-23, (242) зачем этот выбор , Аноним (86), 17:53 , 20-Сен-23, (86) +1 // Потому что один размер на всех - не катит Кому-то надо максимальную скорость, а, Аноним (126), 00:08 , 21-Сен-23, (124) // Еще скорость разжатия почти не меняется даже после запаковки хоть с самым высоки, fumanchez (ok), 01:47 , 21-Сен-23, (134)   // У LZ-based все три именно оно есть довольно большая асимметрия по ресурсам на , Аноним (-), 02:09 , 21-Сен-23, (137)   btrfs жмет не файл целиком, а его куски по 128 КБ, поэтому тут навряд ли количес, fumanchez (ok), 11:40 , 21-Сен-23, (162)   А таки - некая зависимость плотность сжатия vs скорость остается Поэтому сие де, Аноним (-), 19:49 , 21-Сен-23, (210) +1   Пожалуй да, хоть zstd 1 неожиданно хорошо себя показал в плане сжатия, но ради и, fumanchez (ok), 22:02 , 21-Сен-23, (224)   Zstd делал тот же кодер что LZ4, это творение Cyan а Технически это что-то тип, Аноним (-), 02:41 , 22-Сен-23, (230)   Вчера таки еще разок заглянул на страничку Compression в доке btrfs, и оказывает, fumanchez (ok), 13:33 , 22-Сен-23, (240)   LZO по смыслу похож на LZ4, тоже скоростной 1-компонентный алгоритм, с прицелом , Аноним (-), 02:35 , 23-Сен-23, (262) +1   Я смотрю в первую очередь на скорость разжатия, все-таки данные пишутся один раз, fumanchez (ok), 15:17 , 23-Сен-23, (268)   Ну как бы в итоге все состоит из времени чтения времени распаковки, и оптималь, Аноним (-), 16:04 , 25-Сен-23, (286)   Мне лично задержки не критичны и большая часть пользовательских данных мне видит, fumanchez (ok), 20:49 , 25-Сен-23, (288)   Ну как, в случае быстрой SSD хи на умеренном проце скорость записи zstd может за, Аноним (-), 19:48 , 26-Сен-23, (291)   Кстати раз уж btrfs выбрали жать фиксированные куски, то может когда-нибудь они , fumanchez (ok), 22:23 , 21-Сен-23, (226)   Боюсь вам ОЧЕНЬ не понравится размер таких таблиц Для них даже ZFS с его зеттаб, Аноним (-), 03:19 , 22-Сен-23, (232)   Ну да, тут херню сказанул, да и таблицы для паролей еще и под укороченный алфави, fumanchez (ok), 13:38 , 22-Сен-23, (241)   Меньше, конечно, но не настолько уж и сильно меньше фу Мелкоблочное чтение даже, Kuromi (ok), 16:35 , 27-Сен-23, (297)   Предположу, что, как Горк и Морк одно жмёт быстро, но слабо, а другое долго, но, Пряник (?), 15:43 , 21-Сен-23, (182) У F2fs тоже несколько на выбор Это нынче норма, главное чтобы в будущих обновле, Kuromi (ok), 14:01 , 22-Сен-23, (243) Когда смотрел оно было очень монструозным, Анончик (?), 18:48 , 20-Сен-23, (91) Она получается сама себя опережает , Аноним (101), 21:43 , 20-Сен-23, (101) // Да легко Программа новой версии может оказаться быстрее старой из-за улучшения , Аноним (126), 00:09 , 21-Сен-23, (125) неттут RoW, если правильно описано в новости, Аноним (90), 19:19 , 21-Сен-23, (206) Вот уж реально киллер фича, но в комментах почему-то спорят о совсем другом, Аноним (200), 17:41 , 21-Сен-23, (200) +1 // ZFS такую особенность имеет с рождения, Аноним (209), 19:42 , 21-Сен-23, (209) –1 // отродясь не имел тут layered storage а не т-пой да еще и де-факто неработающий к, пох. (?), 20:33 , 21-Сен-23, (213) // Ну да В общем то Кент достаточно забавно понял как еще можно с write-anywhere р, Аноним (-), 21:56 , 21-Сен-23, (223) Подождите минуточку, давайте посмотрим на второй абзац новости К пулу ZFS при же, Аноним (209), 23:07 , 22-Сен-23, (256) Может вас еще и авто-репайр битой копии с исправной настораживать станет Хороши, Аноним (-), 02:42 , 23-Сен-23, (263) Видимо не всем столько счастья надо и не все понимают что вообще можно вытворять, Аноним (-), 21:53 , 21-Сен-23, (222) Устарело, нынче модно всё на ssd или nvme, Аноним (66), 07:15 , 22-Сен-23, (234) // Хранить жирные рипы и прочие медиафайлы на SSD все еще не особо модно Записывае, Kuromi (ok), 14:05 , 22-Сен-23, (245) // причем записываешь тоже не из мегаскоростного источника, откуда бы ему такому вз, пох. (?), 15:36 , 22-Сен-23, (246) Теоретически модный bcache при записи должен пихнуть рип на SSD, потом потихоньк, Kuromi (ok), 23:30 , 22-Сен-23, (257) Это под гибриды где HDD и SSD в одном девайсе Зонирование - немного не про то , Аноним (-), 02:49 , 23-Сен-23, (264) ага Напоминаю - откуда он взялся-то Правильна - либо с флэшки, либо с интернет, пох. (?), 09:13 , 23-Сен-23, (267) Если кэш не совсем тупой он статистику вести будет - и забуферит даже не весь bu, Аноним (-), 16:13 , 25-Сен-23, (287) Ну так для тех же быстрых NVME даже в тестах данные льются чтобы скорость провер, Kuromi (ok), 16:14 , 27-Сен-23, (296) Так это наследие от Bcache, который собственно это и делал - кэшировал HDD на SS, Kuromi (ok), 14:03 , 22-Сен-23, (244) // то, как в первых имплементациях было реализовано, было напрямую взято из bcache,, rinat85 (ok), 23:29 , 26-Сен-23, (292) Без длинных имен файлов и 16 битных символов так же не нужна как Btrfs, ZFS, Lin, Аноним (266), 05:16 , 23-Сен-23, (266) +1 1,2,5,10,11,13,14,21,24,50,55,66,74,86,91,101,200,266

Сообщения

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

	134. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 21-Сен-23, 01:47
	Еще скорость разжатия почти не меняется даже после запаковки хоть с самым высоким уровнем. Может быть актуально для внешнего диска.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от Аноним (-), 21-Сен-23, 02:09
	> Еще скорость разжатия почти не меняется даже после запаковки хоть с самым > высоким уровнем. Может быть актуально для внешнего диска. У LZ-based (все три именно оно) есть довольно большая асимметрия по ресурсам на сжатие и распаковку. В первом приближении, сжатие LZ - поиск совпадений, чем длиннее, тем лучше. Это довольно ресурсокмко, как ни крути. Особенно "чем длиннее" до упора. Чем больше ресурсов на это убито тем лучше может получиться совпадения нащупать и меньше данных на выход. С тем же самым результаом декодирования. И уровень сжатия - регулирует в общем то в какой момент matchfinder'у надоест пытаться нащупать наилучшее, и он посчитает что то что есть - "good enough", и отдаст результат. При распаковке это фактически следование инструкциям вида "скопируй X байтов от сих до сих". Там нечему так уж тормозить. И от уровня сжатия структура этого мало зависит. Иногда даже улучшение может быть от повышения уровня - ведь с точки зрения распаковки, "на вход немного меньше, результат точно такой же" - и суммарный результат сведется к "немного разгрузили шины" т.е. даже еще и сэкономили какие-то крохи времянок. Реальность конечно чуть сложнее - у gzip и zstd еще уровень "кодирования энтропии" поверх этого. LZ4 чистый LZ, он целиком про скорость и поэтому с кодированием энтропии там не заморачиваются (сильно скорость распаковки рушит, хоть и улучшает сжатие). Но общая идея что распаковка LZ быстрая - остается. LZ4 конечно самый быстрый на расппковку, у него нет дожатия энтропии и формат потока рыхлый, зато простой в парсинге.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 21-Сен-23, 11:40
	> В первом приближении, сжатие LZ - поиск совпадений, чем длиннее, тем лучше. btrfs жмет не файл целиком, а его куски по 128 КБ, поэтому тут навряд ли количество совпадений будет сильно отличаться при разных уровнях сжатия, а решать будет скорее то, как алгоритм отрабатывает в среднем, но я не шарю. Страдают только экстенты жирных файлов - на каждый скомпрессированный кусок надо хранить метаданные, и по идее это тоже бьет по времени доступа к содержимому из-за фрагментации, но я чето уже и не помню где глянуть бенчмарки, чтобы оценить какой выигрыш дает хранение файла "сплошняком".
	Ответить | Правка | Наверх | Cообщить модератору

	210. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+1 +/–
	Сообщение от Аноним (-), 21-Сен-23, 19:49
	> btrfs жмет не файл целиком, а его куски по 128 КБ, поэтому > тут навряд ли количество совпадений будет сильно отличаться при разных уровнях сжатия, А таки - некая зависимость плотность сжатия vs скорость остается. Поэтому сие делают выбирабельно. Если у вас супербыстрый SSD а проц маломощный вы наверное LZ4 на минималках хотели. А если тормозной винч, на мощном проце, вас и zstd с солидной степенью сжатия не напряжет, а IO немного убавится. Как и суммарное время операции. Ну да, может на несколько процентов. > а решать будет скорее то, как алгоритм отрабатывает в среднем, но я не шарю. Ну вон то и определяет что будет в среднем. Низкие уровни - вырубают matchfinder рано. Поэтому жмет заметно быстрее, хоть и хуже. А какое соотношение оптимально в конкретном случае - зависит от деталей. И может завести в довольно дальние дебри pareto frontier'а, у этих, от сжатия, свои граали тоже есть. > бьет по времени доступа к содержимому из-за фрагментации, но я чето > уже и не помню где глянуть бенчмарки, чтобы оценить какой выигрыш > дает хранение файла "сплошняком". На механике фрагментация это фу. На SSD - сильно меньше фу, можно не очень париться. А большой непрерывный экстент всяко эффетивнее кучи мелочи. Вопрос в масштабе эффекта и стоит ли оно заморочек в конкретном случае.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 21-Сен-23, 22:02
	> Если у вас супербыстрый SSD а проц маломощный вы наверное LZ4 на минималках хотели. Пожалуй да, хоть zstd:1 неожиданно хорошо себя показал в плане сжатия, но ради интереса перегоню на днях хомяк в lz4, не думаю, что он пожмет сильно хуже. А для раздела с играми на харде zstd:6 оказался хорошим выбором, не заметил каких-то заметных просадок в еле идущей на этом ноуте Baldur's Gate 3 (а я еще и сейвскамер). Но я пока не могу определиься с 2-мя разделами - корень (тут у меня пока с древних времен ext4) и раздел с гит-репозиториями (а тут xfs, просто надеюсь, что она хоть что-то дедуплицирует). Корень это пожалуй рекордсмен по количеству операций чтения, и постоянное разжатие это повышенное использование процессорного времени. А репозиторий с сорцами ядра или просто папка node_modules это тонна файлов, а у btrfs как раз основная проблема, что она неадекватно распухает от метаданных. Так что в обоих случаях может оказаться, что игра не стоит свеч. Может быть даже есть смысл вместо btrfs смотреть в сторону zfs, ведь по идее ноутбучная DDR память довольно энергоэффективная, а сама zfs более продвинута в плане размещения данных на диске.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от Аноним (-), 22-Сен-23, 02:41
	> Пожалуй да, хоть zstd:1 неожиданно хорошо себя показал в плане сжатия, Zstd делал тот же кодер что LZ4, это творение Cyan'а. Технически это "что-то типа LZ4" но - мощнее, жирнее и с entropy coder за ним, на основе новомодного ANS от Jarek Duda. По своему забавное комбо. Потому что как минимум точно может по степени сжатия дать мастеркласс gzip'у, на топовых уровнях почти садясь на хвост грандам типа LZMA (который слоупок) и Brotli (этот читерит, и "в чистом виде" не так уж крут) - но при этом даже быстрее в распаковке. Смысл брать gzip при существовании zstd минимальный, но видимо уже были тома с вот этим, не обламывать же их?! LZ4 технически в общем случае быстрее за счет отсутствивя entropy coding за ним. Но и жмет он хуже в результате. Так что оптимальность штука многогранная. Уровень сжатия zstd актуален если много ЗАПИСЫВАТЬ и быстро: на высоких уровнях да с хилым процом это может в проц упереться, недогрузив девайс на ЗАПИСЬ. Распаковка в разы быстрее и ее скорость не сильно зависит от поюзаного уровня. Врядли baldurs gate много ЗАПИСЫВАЕТ. Зачем гамесе много записывать? А на распаковку - там еще зависит жатые ли у него ресурсы или нет. Некоторые гамесы сами сжатые типа-архивы юзают, им с сжатия в ФС мало что перепадет. А если ассеты не сжатые тогда сжатие что-то отыграет. Что до XFS сам по себе ничего не дедуплицирует. Но с неких пор его таки научили в рефлинки. И можно сделать "thin" копию которая изначально ссылается на блоки оригинала а дальше по мере расхождения обеспечивает абстракцию что это независимые файлы. Изначально фокус btrfs, но XFS а недавно наконец и ZFS этому научили. Сабж тоже это вероятно или умеет или скоро будет уметь, куда оно денется, для cow стыдно такую семантику не уметь. В btrfs также можно и оффлайн-дедупнуть идентичные файлы тулсами типа jdupes. Хз, может уже и на XFS работает если оно заимплементило "same extent ioctl", для XFS я это не проверял. После их демарша с выносом v4 в obsolete без путя конверсии в v5 я их разобрал и btrfs'ом сделал, коли уж крушить так пусть тогда и cow полноценный и управление местом по первому классу. Они вон scrub и автопочинку до сих пор осилить не могут, да и многодевайсность там это боль. > zstd:6 оказался хорошим выбором, не заметил каких-то заметных просадок в еле > идущей на этом ноуте Baldur's Gate 3 (а я еще и сейвскамер). Да я и сам zstd местми юзаю на btrfs. Главное /boot в zstd не сжать случайно если grub старый и без поддержки zstd, а то тот очень обижается на "unknown compression algo". Каким-то дистрам актуально у каких-то он уже zstd умеет. > это пожалуй рекордсмен по количеству операций чтения, и постоянное разжатие это > повышенное использование процессорного времени. XFS вообще довольно интенсивная по метаданным штука и идея разложить на него пачку репов git как по мне довольно спорная. У меня такое ощущение что даже btrfs его заметно делает на таких нагрузках. При том умея кучу продвинутостей. > проблема, что она неадекватно распухает от метаданных. Так что в обоих > случаях может оказаться, что игра не стоит свеч. Да черт знает, от штук размером с линукскернел вроде не так уж и распухает, я еще рефлинкаю билддиры на оригинала и они и копируются "очень быстро" и места жрут сильно меньше суммарного веса. > Может быть даже есть смысл вместо btrfs смотреть в сторону zfs, ведь > по идее ноутбучная DDR память довольно энергоэффективная, а сама zfs более > продвинута в плане размещения данных на диске. ZFS был самым первым - с фига ему эффективным быть? Это даже еще не экстентный аллокатор, какой-то недопилок с "блоками переменных размеров" как максимум. Поэтому и затыкают его скорость работы гигазами рамы, рамдиски то быстрые. Но с подпором ...цать гиг опертивы что угодно - быстрое. Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым. Btrfs появился позже и их поэтому хватило на нормальные экстенты, tail packing, хранение мелких файлов сразу в деревьях (что быстрее, особенно на механике, не надо головы гонять хз куда, данные сразу доступны). Ессно свои проблемы тоже есть. Но актуальны больше на многодисковых конфигах и особенно желающим продвинутостей типа RAID5/6 и проч. На самом деле крутой и фичастый дизайн, но это же и усложняет доведение до ума в мелких деталях. Самый заметный минус - не делался под "низкий оверхед" с самого начала, на суперскоростных SSD все же заметно. Сабж - дизайнился еще позже. И потому пытается вобрать лучшие черты всех предшественников. Обойдя их недостатки. Серебряных пуль - не бывает. Но в целом - ключевые решения btrfs напоминают но с вниманием к оверхеду и скорости, и вот еще иерархические хранилки, это конечно не для тех кто на разделы что-то нарезает, а для тех кто несколько девайсов хочет, сочетая сильные стороны разнородных устройств. Есть скажем гибриды SSD+HDD где SSD буферизует запись, а потом неспешно сливается на HDD. Сабж делает сие уже софтварно - из того что есть - и подконтрольно владельцу, не требуя гибридных устройств и давая больше контроля над этим аспектом. По своему круто. Если есть HDD и SSD можно получить почти скорость SSD и емкость HDD. Если правильно нарулить вон то. Нюансы конечно будут. Но все же.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 22-Сен-23, 13:33
	Вчера таки еще разок заглянул на страничку Compression в доке btrfs, и оказывается lz4 у них нема, только lzo, так что кажется я вспомнил, почему именно выбрал zstd:1. А так по методам сжатия полностью согласен, для меня есть только lz4, zstd и понемногу уходящий старичок gzip, а всякие xz, bzip2, brotli слишком медленные даже на разжатие. Причем даже zip архивы удобнее, DEFLATE все-таки хорошие цифры показывает. > Зачем гамесе много записывать? F5 - и пошла запись, правда это обычно объемы небольшие, но в процессе игры. > А на распаковку - там еще зависит жатые ли у него ресурсы или нет. На самом деле многие файлы btrfs не трогал, а игру я уже удалил и точно не помню, как она разместилась, вроде игра похудела на 12 ГБ, т.е. почти на 10%. А так, многие игры перестали жать ресурсы и постоянно подгружают какие-нибудь текстуры с диска, и я видел игры, которые даже не тромбуют ресурсы в архив типа tar, а тупо держат каждую текстурочку в виде отдельного файла - интересно как такие пациенты себя поведут. Но игры обычно упираются в GPU, а в CPU по идее должно оставаться немного "воздуха" на незатратное разжатие, так что игоры я буду жмать. > XFS вообще довольно интенсивная по метаданным штука и идея разложить на него пачку репов git как по мне довольно спорная. Ну тут просто надо остановиться на чем-то одном, а xfs (v5) вроде пободрее мейнтейнят и inode он выделяет динамически, значит по идее не должны внезапно закончиться. С дедупликацией только я так и не поигрался, но как-нибудь создам 2 раздела с xfs и btrfs, гляну чего можно добиться для тех же исходников ядра. Особенно интересно, можно ли добиться online дедупликации на моменте git clone. > ZFS был самым первым - с фига ему эффективным быть? > Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым. Вот этого не знал, я думал это btrfs долгое время был вообще непригодным к использованию и до сих пор легко ломается, а zfs сразу бодро встал и пошел за счет удачного дизайна. Надо пожалуй будет матчасть таки прочитать, потому что рассматривание бенчмарков себя не оправдало - по-прежнему многие места не понятны, да и милисекунды - хреновая метрика, как и синтетические случаи, в которых можно израсходовать все место на разделе c btrfs.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+1 +/–
	Сообщение от Аноним (-), 23-Сен-23, 02:35
	> Вчера таки еще разок заглянул на страничку Compression в доке btrfs, и > оказывается lz4 у них нема, только lzo, так что кажется я > вспомнил, почему именно выбрал zstd:1. LZO по смыслу похож на LZ4, тоже скоростной 1-компонентный алгоритм, с прицелом на скорость распаковки. LZ4 не стали встраивать потому что слишком похожие по свойствам алго, и ради чего возиться тогда?! На момент дизайна btrfs LZ4 в ядре еще не было, взяли похожий LZO. Более новые дизайны берут LZ4 т.к. он немного резвее, а степень сжатия при желании скорости все же вторична. Но в целом сравнимые алго подвида "simple LZ". > А так по методам сжатия полностью согласен, для меня есть только lz4, > zstd и понемногу уходящий старичок gzip, а всякие xz, bzip2, brotli > слишком медленные даже на разжатие. Ну дык. Xz это LZMA на стероидах. Жмет круто, но даже скорость распаковки - в разы хуже. Им пользуются когда надо до последнего байта экономить. Как вон тот uboot с вебмордой для для TPLink-ов. Там оно либо втиснется в 64 кил регион со ВСЕМ, либо нет, а больше некуда. Вот и приходится хардкорить, даже если и дольше стартует это лучше чем никак. В менее радикальных случаях скорость его распаковки так себе, даже на initrd - от него заметная на глаз задержка при старте на распаковку, например. А бротли сильно оптимизирован на вебпаги, мухлюя с встроенным предзагруженным словарем. Улучшает сжатие вебпаг - ценой хранения надерганого из них словаря 120 кило в либе. Так что можно сразу ссылаться на совпадения еще не вгрузив данных. А если не вебпага, тогда фокус может и не прокатить и сам по себе он "чуть помедленнее и чуть хуже жмет чем zstd". Поэтому кроме браузеров и вебсерверов мало кем используется. > Причем даже zip архивы удобнее, DEFLATE все-таки хорошие цифры показывает. У deflate словарик склерозный, 32 кило. На больших повторяющихся файлах он не увидит совпадение через мегабайт - и может основательно проиграть на этой почве. По скорости распаковки хуже в основном за счет Huffman vs ANS в второй части. ANS это более забористая абстракция, сочетающая плюсы arithmetic coding в сжатии с скоростью даже лучше huffman, за что и используется в новых кодеках. Эпл что-то тоже делал и сорц даже публиковал, но zstd мастеркласс им дал, потому что Cyan (автор LZ4) и Jarek Duda (создатель ANS) в 1 команде могут порвать на пару много кого, ну zstd и зарулил много кого. Facebook кроме этих 2 и еще пару приличных алгоритмистов нанял, уделать такую тиму нелегко. > F5 - и пошла запись, правда это обычно объемы небольшие, но в > процессе игры. Оно все ж может в буфер улететь, особенно если объемы небольшие, врядли гамеза в том же треде что основное действо будет синкать сэйвы и проч, так что это все может относительно асинхронно случиться если авторы гамесы не совсем дятлы. > на 12 ГБ, т.е. почти на 10%. А так, многие игры > перестали жать ресурсы и постоянно подгружают какие-нибудь текстуры с диска, Ну тут все зависит от конкретики. Бывает и так что ассеты 50/50, т.е. часть сжатые, скажем PNG какой или текстуры пакованые, а часть - жмется. > tar, а тупо держат каждую текстурочку в виде отдельного файла - > интересно как такие пациенты себя поведут. Им в целом перфоманс файлухи актуален. В этом смысле - я бы их на XFS складывать не стал, тот с кучей файлов работает "не очень". А в остальном EXT4/btrfs/f2fs/....  в принципе не особо тормозят с разлапистыми иерархиями. > Но игры обычно упираются в GPU, а в CPU по идее должно оставаться немного "воздуха" на > незатратное разжатие, так что игоры я буду жмать. Ну да. Особенно с крутыми настройками и солидным двиглом, если GPU не самый топовый. Хотя на сильно крутом GPU при заурядном проце может и проца не хватать для прогрузки GPU в каких-то случаях. Но это относительно экзотичный сценарий. Фороникс изредка натыкался и на такое. > Ну тут просто надо остановиться на чем-то одном, а xfs (v5) вроде > пободрее мейнтейнят и inode он выделяет динамически, значит по идее не > должны внезапно закончиться. С дедупликацией только я так и не поигрался, > но как-нибудь создам 2 раздела с xfs и btrfs, гляну чего > можно добиться для тех же исходников ядра. Особенно интересно, можно ли > добиться online дедупликации на моменте git clone. Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. На энтерпрайз файлопомойке то претендентов на RAM и CPU нет, можно все сожрать. А на более обычном компе... ближайшее к этому наверное прога "bees". Некая приблуда строящая базу потенциальных дупов, в том числе и инкрементально могет если в фоне держать. Изначально для btrfs делано но может и с XFS работает, если уж оно рефлинки научилось то может и в "same extent" смогет. Лично для XFS не проверял. >> Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым. > Вот этого не знал, я думал это btrfs долгое время был вообще > непригодным к использованию и до сих пор легко ломается, Ну как, btrfs это довольно большой и сложный дизайн. Его отладка заняла время. И до сих пор RAID5/6 имеет свои нюансы. Для RAID5 частично починеные, 6 еще нет. Если они нужны, читать мануал и думать окей ли оно вот так. И метаданные в RAID1 лучше. Сильно безопаснее. Но он технически более поздний чем ZFS и сделан с оглядкой на него - и попытками обойти неудобные места. Более прозаичные кейсы типа RAID1 вполне юзабельны как по мне. И в целом у дизайна больше задел на будущее. Разопрется ли кто когда ВСЕ его возможности раскрыть - вопрос номер два. Скажем теоретически на btrfs можно разным файлам разную схему хранения давать. Не все файлы одинаково ценны. Практически - ну там и без этого наворотов хватает и слабых мест. > а zfs сразу бодро встал и пошел за счет удачного дизайна. Ага, конечно. Его тоже так то отлаживали дофига, своих грабель у него тоже есть, scope у него изначально меньше - энтерпрайзные файлохранилки, btrfs более универсальный. А технологии тогда были менее развиты. Так что максимум на что их хватило это блоки переменного размера, сильно меньше нормальных экстентов, значит оверхеда в метаданных больше. С чего этому быстрому быть только фаны марки и знают. А с десятками гиг буферов что угодно "быстрое". > Надо пожалуй будет матчасть таки прочитать, потому что рассматривание бенчмарков себя не > оправдало - по-прежнему многие места не понятны, да и милисекунды - > хреновая метрика, как и синтетические случаи, в которых можно израсходовать все > место на разделе c btrfs. Бенчмарки бывает довольно сложно интерпретировать - да и насколько оно похоже на то что вон там актуально - как повезет. Самое очевидное - cow'ать большие нагруженные базы неважная идея. Но это надо не всем и не всегда, а btrfs умеет для этого no-cow, становясь чем-то типа EXT4 для таких файлов. Но и все плюсы cow типа снапшотов и чексум при этом в ауте. Zfs и это не умеет и постепенно может зафрагментиться в хлам. А дефрагера у него как я помню совсем нет. На самом деле лучше всего попробовать самому и что понравится и пойдет под требования то и оставить. Бенчи это прекрасно а юзать все же не автору бенчмарков. Вот сабж - обещает быть интересным и крутым. Но опять же - он даже еще не в основном майнлайне, и пока из него лажу вытряхнут - ну это будет вовсе не моментально. И займет сколько-то лет, вероятно. А Кент узнает много нового о том что его файлуха может отколоть, как фэйлят девайсы у юзеров, ... :) но это будет интересная дорога в будушее.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 23-Сен-23, 15:17
	> LZO по смыслу похож на LZ4 > Более новые дизайны берут LZ4 т.к. он немного резвее, а степень сжатия при желании скорости все же вторична. Я смотрю в первую очередь на скорость разжатия, все-таки данные пишутся один раз, а читаются потом всегда. А разжатие у lz4 заметно быстрее, чуть ли не в 1.5-2 раза. Я в основном тут смотрю цифры http://quixdb.github.io/squash-benchmark, странно правда, что там zstd только с 1 уровнем, но зато наглядно. В частности на графиках Ratio / Decompression видно, что lzo и lz4 вообще в разных областях располагаются, а zstd по скорости разжатия рядом с lzo, вот только он еще и жмет. Я правда из датасетов там только enwiki и mozilla глядел, может для обычного десктопа оно и нерелевантно, да и gcc и дистры какие-то старые, может есть смысл на локалхосте погонять. Хотел тогда на раздел с /home lz4 с высоким уровнем, но подумал, что и zstd:1 пойдет, а lzo - точно мимо. > Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. Вроде на бумаге задача решаемая, пусть и с небольшим количеством приседаний. Если git clone делать в tmpfs или ramfs достаточного размера, тут уже ФС сможет оценить все, что будет писать на диск, и решить как это лучше всего разместить, в т.ч. и с онлайн дедупликацией. Выигрыш может будет и сомнительный, но если есть на это ресурсы - почему бы так не делать? > ближайшее к этому наверное прога "bees" Это я так понял демон, который всю ФС смотрит, и опять же это оффлайн. А хотелось бы сразу скинуть на диск дедупнутую директорию. Да и обычно пользователю виднее, где могут быть потенциальные дубликаты, и проще "дедупликатор" ручками натравлять, чем мониторить диск 24/7. > лучше всего попробовать самому и что понравится и пойдет под требования то и оставить Да на самом деле все ФС нормально работают и не требуют к себе повышенного внимания, особенно при обычной десктопной нагрузке. Вопрос скорее в том, что из ФС можно выжать и какой ценой.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от Аноним (-), 25-Сен-23, 16:04
	> Я смотрю в первую очередь на скорость разжатия, все-таки данные пишутся один > раз, а читаются потом всегда. А разжатие у lz4 заметно быстрее, > чуть ли не в 1.5-2 раза. Ну как бы в итоге все состоит из времени чтения + времени распаковки, и оптимальность сочетаний не константа и варьируется в зависимости от кучи факторов. В целом LZO относится к примерно тому же классу алгоритмов (скоростные "простые LZ") и профит от +1 алго по мнению девов btrfs в их кейсе умеренный. А вот например пожмешь /boot LZ4 а загрузчик и скажет "unknown compression", +1 алго в ФС не так уж безобидно. > Я в основном тут смотрю цифры http://quixdb.github.io/squash-benchmark, На самом деле это очень многофакторное и зависит от ряда соотношений (например мощь CPU и скорость RAM vs IO) и по факту лучше бенчить именно у себя на именно интересных кейсах. А чужие тесты в лучшем случае позволят ожидаемые соотношения прикинуть. Если понимать на что смотреть. > странно правда, что там zstd только с 1 уровнем, но зато наглядно. Ну как бы на более высоких уровнях жать будет медленнее. Распаковка примерно так же останется. Зависимость уровень vs скорость распаковки бывает, но слабая. > В частности на графиках Ratio / Decompression видно, что lzo и lz4 вообще > в разных областях располагаются, а zstd по скорости разжатия рядом с lzo, > вот только он еще и жмет. ИМХО LZO в целом поплотнее LZ4, а в ФС с требованием на рандомный seek и потому лимитом на размер блока zstd  негде на полную разогнаться. И таки LZO побыстрее zstd во многих случаях и инициализация дешевле: поток LZ4 и LZO можно распаковывать с места в карьер, zstd и zlib в этом более навернуты и надо состояние entropy coder еще инитить. > Я правда из датасетов там только enwiki и mozilla глядел, может для > обычного десктопа оно и нерелевантно, Учитывая что у ФС требование на рандомный доступ и потому лимит на размер блока - соотношения несколько изменятся. Сетап распаковки роялить больше будет. > с /home lz4 с высоким уровнем, но подумал, что и zstd:1 > пойдет, а lzo - точно мимо. Lzo имхо будет быстрее хоть какого zstd в тех случаях (на распаковку). У него фора есть, это "простой LZ" с довольно тривиальным потоком, как и LZ4, можно с места в карьер его распаковывать, даже без аллокаций памяти не говоря про инит кодера энтропии. А zstd куда навернутее, и такая развлекуха на каждый блок отольется по идее... >> Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. > Вроде на бумаге задача решаемая, пусть и с небольшим количеством приседаний. Да и на практике решаемая, только это как компрессия с супер-большим словарем и потому оперативы немеряно жрет и CPU грузит весьма прилично. И хотите ли вы это все вот именно в момент записи - очень отдельный вопрос. Офлайн дедупы позволяют выбрать момент когда ресурсы тратить более контролируемо, отложенно. А штуки типа bees могут и околореалтаймно пахать, сканируя дельту относительно прошлого забега и дедупая только это. Но и так можно себе "windows vista" организовать, когда оно все время что-то делает и грузит систему. > Если git clone делать в tmpfs или ramfs достаточного размера, тут уже > ФС сможет оценить все, что будет писать на диск, Проблема в том что для более-менее быстрого поиска дупов в RAM надо держать немеряную хештаблицу всех кандидатов, иначе скорость операции будет совсем печальной. Требует дофига рам, пропорционально объему стоража. Офлайн дедупалки могут пытаться какой-то компромисс с хранением индекса кандидатов в базе, так медленнее но снижает аппетиты к RAM. Которые могут начать измеряться десятками гигов на большом стораже. > и решить как это лучше всего разместить, в т.ч. и с онлайн дедупликацией. Проблема в том что процесс принятия решения чем-то напоминает сжатие в LZ (поиск совпадения хоть и с рядом ограничений) - ни разу не халявен по ресурсам. > Выигрыш может будет и сомнительный, но если есть на это ресурсы > - почему бы так не делать? Ну вот поэтому ZFS с онлайн дедупом только на файлопомойках с кучей ресурса и юзают, там все равно CPU и RAM может быть некуда деть. А если это не выделенная файлопомойка то на проц и раму и другие претенденты есть. > Это я так понял демон, который всю ФС смотрит, и опять же это оффлайн. Это примерно на границе миров. Поскольку именно демон, и может процессить именно дельту, мониторя изменения, это начинает напоминать онлайн. А совсем оффлайн - это именно прога, не демон, пинаемая мануально по усмотрению юзера. Например jdupes или duperemove. Они ресурсы сами по себе не жрут совсем. > А хотелось бы сразу скинуть на диск дедупнутую директорию. В конечном итоге что так будет эн референсов на 1 экстент из метаданных что сяк. Отличия будут только на интервале пока дуп не отпроцессили. В ZFS это настолько ресурсоемко вышло что пользуется этим довольно мало кто в именно таком виде. Это вот реально для энтерпрайзных файлопомоек выделенных под задачу, на жирной машине. > Да и обычно пользователю виднее, где могут быть потенциальные дубликаты, и > проще "дедупликатор" ручками натравлять, чем мониторить диск 24/7. Ну я как-то так и предпочитаю, чтобы вместо виндоус висты концентрированный жор ресурсов когда мне точно пофиг, скажем пока я сплю. Вон парочка примеров этсамого. >> лучше всего попробовать самому и что понравится и пойдет под требования то и оставить > Да на самом деле все ФС нормально работают и не требуют к > себе повышенного внимания, особенно при обычной десктопной нагрузке. Вопрос скорее в > том, что из ФС можно выжать и какой ценой. Ну я вот из btrfs выжал нехилое улучшение надежности моих систем за счет парирования единичных бэдов, вплоть до того что на сыпучей флехе можно стало таскать файло. EXT* там за месяц в хлам разваливается, а btrfs живет уже пару лет с схемой DUP - чтобы выбило обе копии блока в разных физических смещениях я должен нехилый такой джекпот у теорвера сорвать. С законами природы не стоит спорить, гораздо лучше ими пользоваться себе во благо :). Или снапшоты. Почти как виртуалка. Не понравился результат апдейтов операционки? Снес полхомяка? Автор лох и сделал "rm /usr /bin/..." как в bumblebee? Ну ок, я откачусь на снапшот в котором все было ЗБС. Ведь сделать его моментально, второй раз хранится только "дельта", а в результате управление почти как в виртуалках. Удобно. Но при этом лучше понимать как работает гипердрайв этого крейсра, в частности cow vs снапшоты vs "хранение дельты". Иначе будут вопросы куда место делось. На виртуалках все то же самое.
	Ответить | Правка | Наверх | Cообщить модератору

	288. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 25-Сен-23, 20:49
	> Ну как бы в итоге все состоит из времени чтения + времени распаковки, и оптимальность сочетаний не константа и варьируется в зависимости от кучи факторов. Мне лично задержки не критичны и большая часть пользовательских данных мне видится похожей на man'ы, которые в .gz и в основном пылятся. А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр, т.е. где в идеале никакой компрессии нет, но нужно как-то обойти ограничения по объему или пропускной способности. И вот в таких сценариях логичнее было бы брать начиная с самого быстрого, то бишь lz4, а если затык останется, то пробовать шаманить с уровнями сжатия или брать lzo. > На самом деле это очень многофакторное и зависит от ряда соотношений (например мощь CPU и скорость RAM vs IO) и по факту лучше бенчить именно у себя на именно интересных кейсах. Подход а-ля Gentoo конечно дает плоды, и при желании можно заморочиться, но бенчить все подряд времени не хватит, а качественных и актуальных замеров очень мало. А так, если есть результаты на разном железе и для разных данных, как на том же Squash Compression Benchmark, то по ним вполне можно делать выводы. Хотя я уже понемногу пилю свои бенчмарки, с упором на то, что лежит в /usr - шрифты, иконки, маны, бинарники и т.д.. > ИМХО LZO в целом поплотнее LZ4, а в ФС с требованием на рандомный seek и потому лимитом на размер блока zstd  негде на полную разогнаться. 128 КБ это не такой уж и маленький блок, я пощелкал графики и для файлов даже поменьше этого блока - в принципе динамика не сильно отличается. > И таки LZO побыстрее zstd во многих случаях и инициализация дешевле: поток LZ4 и LZO можно распаковывать с места в карьер, zstd и zlib в этом более навернуты и надо состояние entropy coder еще инитить. Ну да, это разные весовые категории, но zstd в своей лидер, а lzo - середнячок. > Да и на практике решаемая, только это как компрессия с супер-большим словарем и потому оперативы немеряно жрет и CPU грузит весьма прилично. И хотите ли вы это все вот именно в момент записи - очень отдельный вопрос. Вот клонирование жирной монорепы - это тот случай, когда придется ждать, а потом еще и скорее всего npm install делать. RAM и CPU в это время прохлаждаются - любимый VS Code или IntelliJ Idea еще не запущены, а Dota 2 не может загрузить все ваши 32 ГБ оперативы и 16 ядер Threadripper'а. Так что вот он момент, чтобы отжать кусок RAM'ы и начать онлайн-дедупить. > Ну я вот из btrfs выжал нехилое улучшение надежности моих систем за счет парирования единичных бэдов, вплоть до того что на сыпучей флехе можно стало таскать файло. Флешки к сожалению приходится держать в exfat / ntfs, а btrfs даже Ventoy не понимает. И как же я пожалел, что давно создал exfat раздел на ЖД под файлопомойку - прав доступа нет, преаллокации нет, уменьшить - хрен. Лучше уж ntfs, если нужен доступ из под винды и линукса. А теперь и вовсе может быть, что btrfs на эту роль подходит лучше, т.к. под винду есть драйвер, который ставится в пару кликов. > Или снапшоты. Почти как виртуалка. Мне бы их лет 15 назад, когда я обвешивал модами Обливион без всяких мод-менеджеров.
	Ответить | Правка | Наверх | Cообщить модератору

	291. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от Аноним (-), 26-Сен-23, 19:48
	> Мне лично задержки не критичны и большая часть пользовательских данных мне видится > похожей на man'ы, которые в .gz и в основном пылятся. Ну как, в случае быстрой SSD'хи на умеренном проце скорость записи zstd может заметно обвалить. А там еще чексумы считать надо, том тоже на скорость. В этом месте LZ4 и LZO деланные под "реалтаймное сжатие" получают пойнт. > А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр, Ну вообще я zram и с LZ4 или ща LZO+RLE модно у них стало. Довольно хорошее, кстати, комбо. RLE уменьшает тупняки на сжатие избыточных последовательностей коих в раме есть, в паре с LZO довольно хорошо жмет, там вопрос в том что либо сожмется минимум в 2 раза, и тогда профит, или нет - тогда зря сожрали ресурсы: там округление до страницы ради скорости. Можно 2 в 1 паковать. Или опциональный 3 в 1 (если данные позволили, конечно). Там рыхлость LZ4 икается больше: если 2x сжатие не вышло, проц тратили вообще зря. ...и в результате OOM с таким "свопом" без выгрузки в файлы/разделы - это секунд 5 просадки перфоманса, а потом OOM killer вынесет обжору. И никаких тупняков минутами как с свопом на дисках. > т.е. где в идеале никакой компрессии нет, но нужно как-то обойти ограничения > по объему или пропускной способности. Я в случае zram ничего не обхожу - я неспешно и в фоне оффлоажу оперативу от "cold" данных в их сжатый вариант, ну оно и выигрывает 2-3x от размера выделенного на zram региона. Даже мелкороутеру нормально - и будучи ram2ram сильно меньше причин тормозить. Если сжатие быстрое. > И вот в таких сценариях логичнее было бы брать начиная с самого быстрого, то бишь lz4, > а если затык останется, то пробовать шаманить с уровнями сжатия или брать lzo. На момент дизайна btrfs в ядре lz4 еще не было. А потом... см. про бутлоадер например. Хотя вон у кента, да и btrfs zlib так то тоже есть, не прокатывать же обладателей томов. > Подход а-ля Gentoo конечно дает плоды, и при желании можно заморочиться, но > бенчить все подряд времени не хватит, а качественных и актуальных замеров > очень мало. Их мало потому что те кто их может - понимают ограниченную ценность результата (привязано к конфиге и кейсу) в паре с тем что в других случаях соотношения могут быть иные, и им есть чем заняться. > по ним вполне можно делать выводы. Хотя я уже понемногу пилю > свои бенчмарки, с упором на то, что лежит в /usr - шрифты, иконки, маны, бинарники и т.д.. Хе, забавно. Ну и да, вот что-то такое неплохо жмется так то. > 128 КБ это не такой уж и маленький блок, я пощелкал графики > и для файлов даже поменьше этого блока - в принципе динамика не сильно отличается. Ну и не такой уж большой - на более жирных блоках скажем zstd vs zlib будет сильнее в пользу zstd. А на файлухе это менее выражено, 32 кил словарь не такая уж трабла если максимум 128К на все. И да, лидеры и аутсайдеры могут меняться от задачи. Я лю с simple LZ развлекаться. Скажем то что рулит на мелких блоках не обязано на бошьших рулить. И наоборот. Многое зависит от деталей формата потока vs макс словарь vs как оно match(offset, len) кодирует и есть ли у формата бонусы. У LZ4 неудачное (по степени сжатия) кодирование больших чисел, на хорошо жмущихся данных он заметно проигрывает хоть тому же LZO, у коего более продвинутый и компактный формат, в LZ4 в угоду скорости в жертву принесено вообще совсем все. Он вообще сильно плотно жать не может даже если данные хорошо жмутся, формат потока лимитирует. Длинный match или match на большом смещении требует куда больше байтов на кодирование чем в даже большинстве иных "simple LZ". За это ratio временами таки хромает. > Ну да, это разные весовые категории, но zstd в своей лидер, а > lzo - середнячок. А LZ4 это довольно экстремальный случай где ради скорости даже формат потока довольно дурной и в плотное сжатие он за это совсем не умеет, на уровне формата потока прямо. Так что есть ряд не очень известных перепевок где народ пытается жать поплотнее, не пролюбив особо скорость распаковки. Некоторые штуки при том на именно мелкие блоки специализируются. Их характерных представителей - lzsa, zx0 и тому подобное. Они не на это ориенитированы но с учетом ориентации на мелкие блоки возможно это не так уж плохо и для ФС было бы. > Вот клонирование жирной монорепы - это тот случай, когда придется ждать, а > потом еще и скорее всего npm install делать. RAM и CPU > в это время прохлаждаются - любимый VS Code или IntelliJ Idea > еще не запущены, а Dota 2 не может загрузить все ваши > 32 ГБ оперативы и 16 ядер Threadripper'а. Так что вот он > момент, чтобы отжать кусок RAM'ы и начать онлайн-дедупить. Ну тогда в случае какихнить bees и пустить их в "околореалтаймном" варианте, там наверное нормально. И это... т.к. файлуха всегда активна, она это все время хочет жрать. > Флешки к сожалению приходится держать в exfat / ntfs, а btrfs даже Ventoy не понимает. Ну мне на ventoy пофиг, для загрузочной флехи я делаю условно "инсталл моего десктопа на флеху". А если занесло на совсем чужой комп, есть стебная штука - WinBTRFS :). Не буду настаивать что это всегда и для всех, но... > И как же я пожалел, что давно создал exfat раздел на ЖД под файлопомойку - прав > доступа нет, преаллокации нет, уменьшить - хрен. Последний писк 90х прошлого века... > Лучше уж ntfs, если нужен доступ из под винды и линукса. > А теперь и вовсе может быть, что btrfs на эту роль подходит лучше, т.к. > под винду есть драйвер, который ставится в пару кликов. Ну да. WinBTRFS называется. И NTFS лично меня вымораживает скоростью работы с большими иерархиями. Если туда расжать что-то размером с линукскернел... ммм... не сильно то оно лучше ExFAt'а ощущается. >> Или снапшоты. Почти как виртуалка. > Мне бы их лет 15 назад, когда я обвешивал модами Обливион без > всяких мод-менеджеров. Да я бы тоже не отказался так то - чтобы cp --reflink'ать например образа винчей с которых файло восстанавливаю. Ну тут уж упс. Даже, вот, прикольные алгоритмы сжатия для мелочи появились - тадам - сильно опосля того как они были сильнее всего нужны. "Опыт это такая штука которая у вас появляется сразу после того как он был нужен" :)
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	226. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 21-Сен-23, 22:23
	> А соотношение оптимально в конкретном случае - зависит от деталей. И может завести в довольно дальние дебри pareto frontier'а, у этих, от сжатия, свои граали тоже есть. Кстати раз уж btrfs выбрали жать фиксированные куски, то может когда-нибудь они вкорячат что-то по типу радужных таблиц для хеш-функций, и будет какой-нибудь вариант с зарезервированной таблицей, где какие-то блоки заранее просчитаны с самыми лучшими параметрами.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	232. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от Аноним (-), 22-Сен-23, 03:19
	> Кстати раз уж btrfs выбрали жать фиксированные куски, то может когда-нибудь они > вкорячат что-то по типу радужных таблиц для хеш-функций, и будет какой-нибудь > вариант с зарезервированной таблицей, где какие-то блоки заранее просчитаны с самыми > лучшими параметрами. Боюсь вам ОЧЕНЬ не понравится размер таких таблиц. Для них даже ZFS с его зеттабайтами маловато будет. Просто для понимания, всего 16 байтов уже 2^128 вариантов значений, комбинаторика штука злая.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от fumanchez (ok), 22-Сен-23, 13:38
	Ну да, тут херню сказанул, да и таблицы для паролей еще и под укороченный алфавит делаются. И какие-то словари уже запихнуты в сам алгоритм. Хотя наверное можно что-то придумать, как-то подшаманить алгоритм под задачу сжатия фиксированных блоков.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
	Сообщение от Kuromi (ok), 27-Сен-23, 16:35
	> На механике фрагментация это фу. На SSD - сильно меньше фу, можно > не очень париться. А большой непрерывный экстент всяко эффетивнее кучи мелочи. > Вопрос в масштабе эффекта и стоит ли оно заморочек в конкретном > случае. Меньше, конечно, но не настолько уж и сильно меньше фу. Мелкоблочное чтение даже на быстрых NVME НАМНОГО медленнее линейного и большого прогресса тут не видно (как минимум пока не откажутся от трансляции, что опять же потребует новых ФС и механизмов выравнивания). А распространение безбуферных дисков эту проблемку еще и усиливает - невозможность разместить всю таблицу трансляции в набортном RAM осложняет скачкообразное чтение по всему диску. В том же Линуксе безбуферники берут от системной памяти 128 (хотя кое где говорят что 256) мегабайт, а обычное соотношение RAM к NAND - 1 мегабайт на 1 гигабайт, т.е. 1 гигабайт буфера под 1 терабайт диска. Жить можно, но становится понятно почему вендоры так любят выпячивать именно линейную скорость.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

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

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