Познаю бтрфс

ого, всё таки запилил, круто получилось, надо будет что то подобное тоже собрать

Дальше предстоит познавать subvolume и снапшоты. И какой-нибудь snapper для их автоматизации, для которого надо правильно обозвать сабволюмы.

Можете сравнить показатели kdiskmark (в прошлом треде есть скриншоты тестов).

Эти raid0 из sata ssd (комментарий)?

бутер с зетом хитроумные машинки.
но тут, судя по всему, простейшая пачка дисков ?? ну эт кажный смогёт :)

беттер зен екст фор?

я интересовался … пришлось разбираться самостоятельно

на LOR часто так

Это все очень круто… до первого отключения питания во время активной записи или отказа одного из накопителей.

При всех достоинствах вся эта конструкция жутко ненадежна.

эта конструкция жутко ненадежна

Тебе нужно в соседний топик ТС raid0 из sata ssd. Там он тоже спрашивал про raid0, предупреждая, что скорость его интересует больше надежности, но ему без конца только и говорили про надежность. :)

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

У меня почти так же, только метаданные не в dup, а в raid1.

RAID0: существует

Я: хочу использовать RAID0

LOR: нет, это ненадежно!

Я думал конечно тут только модераторы тугие, но регистранты не сильно лучше :) Шутка если что, знаю что Всеволод тут как раз один из немногих, кто людям пишет ответы на вопросы, вместо «забаньсядебил»

А я познал bcachefs, вот уже с полгода как, и могу сказать что он круче в плане многодисковых конфигураций, да и вообще. 2 SSD + 3 HDD разных объемов. При этом на подобной конфигурации можно даже аналоги любых RAID массивов намутить используя весь объем дисков и не требуя регулярных scrub/balance для поддержания производительности. Пока еще не поддерживается установка на многодисковый пул, но надеюсь скоро подобное будет и уже полноценно на эту фс перееду. Система пока еще под btrfs на nvme установлена. Монтирую bcachefs пул через сервис systemd при загрузке. Пул монтировался через fstab больно костыльно, а то и вообще не монтировался до недавнего времени. Может уже и пофиксили, еще не проверял.

mount | grep bcachefs
/dev/sda:/dev/sdc:/dev/sdd:/dev/sde:/dev/sdb on /mnt/bchfs-pool type bcachefs (rw,noatime,metadata_replicas=2,compression=zstd:1,background_compression=zstd:3,foreground_target=ssd,background_target=hdd,promote_target=ssd)```

Папоротник :)

беттер лэйт зен невэр

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

До недавнего времени использовал btrfs raid0 на 2x1tb HDD дисках не первой свежести под активную файлопоймоку. Метаданные зеркалировались. За 1-2 года использования словил checksum=error на парочке свежезаписанных файлов, которые быстро нашел и удалил/заменил. И ничего, фс не развалилась. При использовании raid1 битые файлы при запуске scrub бы пофиксились, но производительность и доступное пространство в ущерб надежности мне было важнее. И как показала практика, надежность в raid0 тоже на приемлемом уровне.

надежность
в raid0

/0
(у меня система на raid0)

А прикол в том, что тебе с Btrfs эта скорость и не нужна и-за сжатия: ты, например, записываешь 150 мегабайт, а распакованные они 1,2 гига весят. Это киллер-фича тащем-та без нее btrfs можно было бы использовать только из-за снапшотов

Такое может быть при отключении электричества, но при нем не только можно ошибку записи словить, но может и прошивка SSD слететь

тебе с Btrfs эта скорость и не нужна и-за сжатия

Ты о том, что не нужен raid0, типа с btrfs и так будет охрененно быстро? ) Или о чем?

Да, о том, что не нужен RAID. Для Btrfs подойдет любой даже SATA SSD. Ты не будешь замечать никаких тормозов даже используя все это вместе с LUKS. Да и в конечном итоге все упирается в скорость инторнет-соединения (100 MBit/s ~= 12 MiB/s) либо пропускную способность сетевой карты (1000 MBit/s ~= 128 MiB/s)

Ну вообще, не все так просто. Прозрачное сжатие не то чтобы моментально ужимает 1,5 гб в 500 мб. Там и особенности ввода-вывода и выделение пространства, расчет контрольных сумм, фрагментация (которая даже на ссд зачастую заметна), кол-во снимков, всякие задержки чтения/записи на фоне этого, производительность самого CPU, в конце концов заметно влияют. Потому и возникают просадки производительности со временем. Поэтому и приходится иногда всякие balance запускать даже на одном диске.

баланс нужен для очистки места занятого заголовками.

у меня с этим нормально все:

❯ sudo btrfs f u /
Overall:
    Device size:                 781.22GiB
    Device allocated:            372.06GiB
    Device unallocated:          409.16GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        318.34GiB
    Free (estimated):            229.35GiB      (min: 229.35GiB)
    Free (statfs, df):           229.35GiB
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              426.06MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,RAID1: Size:181.00GiB, Used:156.23GiB (86.31%)
   /dev/mapper/crypt1    181.00GiB
   /dev/mapper/crypt2    181.00GiB

Metadata,RAID1: Size:5.00GiB, Used:2.94GiB (58.88%)
   /dev/mapper/crypt1      5.00GiB
   /dev/mapper/crypt2      5.00GiB

System,RAID1: Size:32.00MiB, Used:32.00KiB (0.10%)
   /dev/mapper/crypt1     32.00MiB
   /dev/mapper/crypt2     32.00MiB

Unallocated:
   /dev/mapper/crypt1    204.58GiB
   /dev/mapper/crypt2    204.58GiB

bcachefs предлагает немного иной подход, к примеру. Да и кэш переднего плана в виде ssd хорошо помогает распределяя и балансируя данные. В самом деле, скорость записи зачастую не так важна, как скорость чтения

Unlike other filesystems that typically do compression at the block level, bcachefs does compression at the extent level - variable size chunks, up to (by default) 128k. When reading from extents that are compressed (or checksummed, or encrypted) we always have to read the entire extent - but in return we get a better compression ratio, smaller metadata, and better performance under typical workloads.

баланс нужен для очистки места занятого заголовками.

Собственно, при регулярном создании снимков, которые мне снаппер создает и удаляет старые при обновлении системы и установке пакетов, скорость чтения проседает. Можно проверить через тот же scrub. У меня на nvme после пары десятков (хотя и стоит ограничение на 12) снимков скорость от ~2 Gb/s проседает до ~1 gb/s. После процедуры balance все приходит в норму

Ну разве что не в два раза, а скорее в полтора раза скорость проседает. В последних релизах ядра много было сделано в сторону производительности и стабильности btrfs. А в 6.9 обещают еще больше оптимизаций

У меня подозрение, что дело в SSD, дисковом кеше и тп, потому как у них скорость падает по мере забития + нужно включить TRIM

ну, discard=async для фс включен

он по умолчанию сейчас, но если вручную запустить:

sudo fstrim -v /

то все равно находит блоки, которые нужно освободить. оно хз как работает

А может и стоит включить по таймеру, да. Тем более у меня есть там еще пара разделов окромя btrfs

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

Вот бы просто ext5 с прозрачным шифрованием, сжатием и рейдом с черепичным режимом по асиметричным разделам...

++

Я пробовал btrfs даже еще когда она сырой была, но в итоге так и не придумал, зачем она мне нужна. Ее главное применение на сегодняшний день это снапшоты и сжатие, все остальное вторично, имхо. Райды? Ну в целом приятно, но объективно, их и через mdadm можно делать и это в некотором смысле удобней… Raid0 был бы немного удобен, если бы файлы не делились между дисками и отвал диска не приводил бы к потере файлов на других дисках, но этого нет и не предвидится.

Разве? Как раз все эти CoW, метаданные, снапшоты, избыточность и контрольные суммыдолжны были сделать ФС хорошо восстанавливаемой хотя бы на сколько то минут до сбоя. На практике я крахов не встречал, в отличии от f2fs.

Raid0 был бы немного удобен, если бы файлы не делились между дисками и отвал диска не приводил бы к потере файлов на других дисках, но этого нет и не предвидится.

Классический рейд0. Причём ехт4 достаточно умна чтобы не нанести себе дополнительных повреждений в случае отвала части раздела. А при реализации рейда на уровне ФС вроде как можно реализовать и дублирование метаданных всей ФС, и какие нибудь приоритеты и сортировку файлов по накопителям. Где то я мельком видел, что в какой то ФС это есть.

Всего то надо какой нибудь lz* задействовать. Нули и он на ноль помножит, а на скорости не скажется даже на третепне.

Рейды достаточно удобная штука. Да и диски сразу и намертво обычно не отваливаются, а всякие переназначенные сектора с ошибками чтения/записи начинают сигнализировать в смарте. Если важных данных в едином экземпляре не хранится, восстановить все необходимое и эвакуировать сыпающийся диск с дальнейшей заменой и перебалансировкой серьезного труда не составит. А в ентерпрайзах, серверах и облаках raid0 и не используют нигде. Да и на нем метаданные зеркалировать надо, что btrfs по умолчанию и делает. Опять же, на уровне самой фс рейды производительнее и стабильнее будут. А уж про шифрование вообще молчу

mdadm не мог сделать мне raid0 как я хотел бы, ему требуются байт-в-байт одинаковые по размеру разделы, а у меня даже два ссд по «256гб» имеют разброс в 5 с копейками гб между собой. А тут в бтрфс еще и 128 залетел и классно!

Да, это понятно, если диски разные.

Классический рейд0. Причём ехт4 достаточно умна чтобы не нанести себе дополнительных повреждений в случае отвала части раздела. А при реализации рейда на уровне ФС вроде как можно реализовать и дублирование метаданных всей ФС, и какие нибудь приоритеты и сортировку файлов по накопителям. Где то я мельком видел, что в какой то ФС это есть.

У меня была такая схема – часть дисков выделить под chia, но потом когда место реально понадобится, то просто вынуть диски из компа и переставить в другой. Если бы при этом повреждался только один файл, то было бы норм, но по факту, btrfs может размещать файлы как угодно между дисками, поэтому может быть утеря скольки угодно файлов и я от btrfs отказался…

Метаданные в ext4 можно вынести на отдельный раздел, как и журналирование… В итоге ext4 у меня основная система уже лет 5, наверное… (до этого была ext3).

Хм, btrfs raid0-10 вообще-то, тоже требовал диски байт в байт, а если какой-то из дисков большего объема, то его объем урезал по размеру меньшего диска, не используя оставшееся пространство. Неужто btrfs научился эффективно использовать все пространство дисков? О_о

Опять же, на уровне самой фс рейды производительнее и стабильнее будут.

Теоретически – возможно, практически – хз. Честно говоря, смысл рейдов сильно уменьшился в последние годы.

Рейд нужен был для двух задач:

1. доступность данных, при отвале диска (редко)

2. скорость (самое частое применение рейда)

п.2 с появлением ssd и nvme стал не нужен, но раньше на HDD я рейд для этого и держал

п.1 в принципе нужен, но в реальности, не так частно, как думают, т.к. очень часто dos на часы не так уж и принципиален, а стоит дофига… Это же не доступность, а не сохранность…

И в самом деле, используется все пространство дисков. Либо раньше этого не было, либо я что-то не так понял, хотя вдоль и поперек перерыл инфу про btrfs пока использовал…

Рассмотрим этот эффект на примере RAID1. В классическом RAID1 данные копируются на столько устройств, сколько включено в массив (собрали raid1 на 3-х дисках 1 GB и получили массив вместимостью 1 GB с тройным резервированием данных). RAID1 в btrfs реализует иную концепцию: гарантируется, что данные будут храниться в двух копиях обязательно на разных устройствах (в отличие от режима DUP). А на 3-х и более дисках обеспечить хранение 2-х копий отдельных фрагментов данных на 2-х разных устройствах можно разными способами. Для примера, если в RAID1 объединены устройства 1Тб, 1Тб и 2Тб, то на 2Тб будет одна копия всех данных, а вторые копии будут распределены между двумя 1Тб устройствами (общий доступный объем на таком массиве будет ~2Тб). В более сложных случаях (больше устройств или все три устройства - разного размера) btrfs будет использовать еще более сложные схемы распределения копий по дискам, но соблюдение правила «2 копии на 2-х разных дисках» обеспечит сохранность данных при выходе из строя любого (одного) устройства. RAID10 также может занимать больше пространства на устройствах разного размера, если этих устройств больше, чем 4.

А не лучше ли для metadata и system использовать RAID1, чтобы наверняка копии имелись на каждом диске? Занимают то места они совсем мало)

Блин, а ведь такое даже профитнее использовать на нескольких hdd, если завалялось несколько таких разных объемов и есть куда воткнуть в материнку. А в режиме RAID1 даже на не самых свежих дисках. Как раз хотелось на работе впихнуть несколько стареньких винтов в старый комп, это ж можно все объединить и систему туда установить

Raid0 был бы немного удобен, если бы файлы не делились между дисками и отвал диска не приводил бы к потере файлов

То что эта идея никем не реализована, само по себе говорит об ее бессмысленности/сложности реализации в виду каких-то пока не очевидных для тебя причин.

У меня RAID-1 - зеркало.

Да, по большому счету она бессмыслена, т.к. можно просто монтировать диски в директории, при больших объемах организация данных проста, а если диски малого объема, то проще завести диски большого обхъема, а потери места ввиду неиспользвоания обычно весьма небольшие…

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

А точно на разные диски? когда я последний раз смотрел, это btrfs не гарантировалось…

Райды? Ну в целом приятно, но объективно, их и через mdadm можно делать и это в некотором смысле удобней

Дело не в том, «удобней» или нет, а в том, что RAID на уровне блочных устройств не умеет обнаруживать «тихие» ошибки (bitrot), а только полные отвалы диска.

Raid0 был бы немного удобен, если бы файлы не делились между дисками и отвал диска не приводил бы к потере файлов на других дисках, но этого нет и не предвидится

Это есть. Просто не включаешь raid0 и всё.

это btrfs не гарантировалось

А что конкретно должно гарантироваться? ФС должна решать задачу покраски графа? :-)

Что файл целиком лежит на одном диске, если диски в raid0. Я утверждений этого в btrfs не вижу. Я не вижу утверждений, что если я выну один диск из raid0 btrfs, то пострадают только файлы принадлежащие этому диску, а фс останется живой.

Обычно, для raid0 каждый файл распределен на всех дисках, это ускоряет работу с ним.