- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., DEF, 11:06 , 19-Июн-23 (1) –25 [V]
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 11:09 , 19-Июн-23 (2) +8 [^]
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 11:10 , 19-Июн-23 (3) +12 [^]
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 11:25 , 19-Июн-23 (8) +5
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 11:28 , 19-Июн-23 (10) +3
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 11:54 , 19-Июн-23 (15) +5
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 12:07 , 19-Июн-23 (16)
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., НяшМяш, 12:22 , 19-Июн-23 (24)
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 12:29 , 19-Июн-23 (25) –1
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Alladin, 12:41 , 19-Июн-23 (26)
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 13:20 , 19-Июн-23 (33) +1
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Администратор, 06:46 , 20-Июн-23 (142)
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., пох., 15:58 , 20-Июн-23 (164)
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., maximnik0, 12:10 , 19-Июн-23 (19) +2
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., анон, 14:42 , 19-Июн-23 (46) +2
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., Аноним, 18:27 , 19-Июн-23 (97)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 11:13 , 19-Июн-23 (4) –1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 11:23 , 19-Июн-23 (7) +3
- Продвижение Bcachefs в состав ядра Linux, Аноним_5, 15:41 , 19-Июн-23 (69) +3
- Продвижение Bcachefs в состав ядра Linux, n00by, 17:02 , 19-Июн-23 (82) +2 [V]
- Продвижение Bcachefs в состав ядра Linux, Дедобот, 17:07 , 19-Июн-23 (85) +1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 11:22 , 19-Июн-23 (5) –1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 22:52 , 19-Июн-23 (110) +1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 00:08 , 20-Июн-23 (117) +2
- Продвижение Bcachefs в состав ядра Linux, Чукча, 15:49 , 20-Июн-23 (163) +1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 19:50 , 20-Июн-23 (186)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 03:40 , 21-Июн-23 (207) –1
- Продвижение Bcachefs в состав ядра Linux и переписывание на ..., YetAnotherOnanym, 11:26 , 19-Июн-23 (9) –3
- Продвижение Bcachefs в состав ядра Linux, аНОНИМ, 11:28 , 19-Июн-23 (11) +4
>> - 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).
- Продвижение Bcachefs в состав ядра Linux, Аноним, 00:18 , 20-Июн-23 (120) +3
- Продвижение Bcachefs в состав ядра Linux, аНОНИМ, 18:47 , 20-Июн-23 (175)
> Буквально пару версий назад радикально заделали для 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 вроде ещё не довпилили, хотя грозятся.
- Продвижение Bcachefs в состав ядра Linux, Аноним, 20:07 , 20-Июн-23 (188) +1
- Продвижение Bcachefs в состав ядра Linux, аНОНИМ, 12:25 , 21-Июн-23 (215)
> У 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'а из нешифрованного сорца в шифрованный дестинейшн.
- Продвижение Bcachefs в состав ядра Linux, Аноним, 22:48 , 21-Июн-23 (225)
- Продвижение Bcachefs в состав ядра Linux, аНОНИМ, 18:32 , 22-Июн-23 (235)
> Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем?Отказ девайса это всё же немного другая ситуация, когда точно известно что данные там-то -- больше недоступны. И тогда даже 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. > А он это не чекает? Проблема была в том, что если шифрованный пустой датасет создать на дестинейшене руками, то в него незашифрованный литься откажется, а если создавать вместе с началом заливки, то там были какие-то нетривиальные проблемы с указанием ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет на дестинейшене перед вливом при помощи ввода пароля).
- Продвижение Bcachefs в состав ядра Linux, Аноним, 18:42 , 20-Июн-23 (173)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 11:53 , 19-Июн-23 (14) +3
- Продвижение Bcachefs в состав ядра Linux, Аноним, 12:11 , 19-Июн-23 (20) [V]
- Продвижение Bcachefs в состав ядра Linux, Анонимусс, 12:48 , 19-Июн-23 (29) –1
- Продвижение Bcachefs в состав ядра Linux, аНОНИМ, 14:42 , 19-Июн-23 (47) +1
бтрфсу конечно не хватает некоторых фич, но других фич не хватает и openZFS. Но вот насчёт глючности я бы поспорил. Я даже специально взгромоздил btrfs на раздел с торрентами, работает цуко и не глючит :) На рутовых разделах она тоже у меня живёт счастливо и радует снапшотами.Конечно, всплывает такая хрень как ужасная фрагментация (по самой сути рандомных записей в файлы при качании торрентов), но встроенный дефрагментатор своё дело делает.
- Продвижение Bcachefs в состав ядра Linux, Витюшка, 14:52 , 19-Июн-23 (55)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 12:45 , 19-Июн-23 (27)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 13:01 , 19-Июн-23 (32) –1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 13:29 , 19-Июн-23 (36) +1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 13:47 , 19-Июн-23 (38)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 14:01 , 19-Июн-23 (40)
- Продвижение Bcachefs в состав ядра Linux, pavlinux, 14:48 , 19-Июн-23 (53) +3
- Продвижение Bcachefs в состав ядра Linux, Unnamed Player, 14:52 , 19-Июн-23 (56)
- Продвижение Bcachefs в состав ядра Linux, Аноним, 14:53 , 19-Июн-23 (57)
- Продвижение Bcachefs в состав ядра Linux, keydon, 15:21 , 19-Июн-23 (64) +1
- Продвижение Bcachefs в состав ядра Linux, Аноний, 15:28 , 19-Июн-23 (66) +1
- Продвижение Bcachefs в состав ядра Linux, Аноним, 18:02 , 19-Июн-23 (95) +1
- Продвижение Bcachefs в состав ядра Linux, fuggy, 21:19 , 19-Июн-23 (101) +1
- Работа по включению Bcachefs в состав ядра Linux, нах., 06:49 , 20-Июн-23 (143) –2
- Работа по включению Bcachefs в состав ядра Linux, Аноним, 07:43 , 20-Июн-23 (144)
- Работа по включению Bcachefs в состав ядра Linux, Пряник, 09:54 , 20-Июн-23 (150)
- Работа по включению Bcachefs в состав ядра Linux, Пряник, 10:19 , 20-Июн-23 (152) +2
- Работа по включению Bcachefs в состав ядра Linux, Минона, 14:22 , 20-Июн-23 (161) –1
- Работа по включению Bcachefs в состав ядра Linux, xsignal, 18:07 , 20-Июн-23 (169)
- Работа по включению Bcachefs в состав ядра Linux, pashev.ru, 08:10 , 21-Июн-23 (208)
- Работа по включению Bcachefs в состав ядра Linux, Аноним, 11:53 , 21-Июн-23 (214)
|