Можно ли задать приоритет дисков в btrfs raid? (делаю объединенный tmp=tmpfs+btrfs)

Зачем тебе RAID силами ФС?

такая фича есть в lvm.
кстати, это вроде jbod зовётся.

Может тебе больше mhddfs подойдет?

Осторожнее там. http://phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-56-Is-Bad

В общем то я сделал то, что хотел:

/etc/systemd/system/tmp.mount

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
Requires=btrfs_tmp.service
After=btrfs_tmp.service

[Mount]
What=/dev/loop0
Where=/tmp
Type=btrfs
Options=defaults,compress=lzo,relatime,noatime,nosuid,nodev,noexec,discard

/etc/systemd/system/mnt-tmpfs.mount

[Unit]
Description=Prepare ramdisk for compressed file image witch btrfs
Before=local-fs.target btrfs_tmp.service tmp.mount
After=systemd-modules-load.service

[Mount]
What=tmpfs
Where=/mnt/tmpfs
Type=tmpfs
Options=defaults,noatime,nosuid,nodev,noexec,mode=1777,size=4096M

/etc/systemd/system/btrfs_tmp.service

[Unit]
Description=Prepare btrfs = tmpfs image+disk image
DefaultDependencies=no
Conflicts=umount.target
Before=tmp.mount
Requires=mnt-tmpfs.mount
After=systemd-modules-load.service mnt-tmpfs.mount

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=/usr/bin/truncate -s 4G /mnt/tmpfs/image0
ExecStart=/bin/mkfs.btrfs -d single -m single /mnt/tmpfs/image0 /mnt/disk/image0
ExecStart=/sbin/losetup /dev/loop0 /mnt/tmpfs/image0
ExecStart=/sbin/losetup /dev/loop1 /mnt/disk/image0
ExecStart=/bin/btrfs device scan /dev/loop0
ExecStart=/bin/btrfs device scan /dev/loop1

В результате монтируется tmpfs, в ней делается файл image0, на диске я тоже такой файл сделал. Потом эти файлы объединяются в btrfs и она монтируется в /tmp

В процессе использования выяснилось, что btrfs по каким то своим соображениям пишет то в tmpfs, то на диск. Вероятно ей лучше знать исходя из скоростей доступа, но это прекраснодушные мечты. Но все пашет. Делалось это потому, что в btrfs есть сжатие. Ну и для развлечения :)

Поищу jbod спасибо.

Можно даже объединить три диска и tmpfs :) Не буду тестировать, останусь в иллюзии, что скорость доступа космическая :)

Попробовав raid0 выяснил, что он скорость доступа радикально понижает по сравнению с single. Так как первым диском идет память. При этом как работает single мне не понятно, так как место на двух image файлах занимается при записи одновременно, но непонятно под данные или метаданные или еще под что. При этом скорость записи в 1.5Гб/с судя по всему говорит о том, что сначала пишется в память и скорее всего это именно linear raid. Но как это точно проверить мне неизвестно.

btrfs выделяет место блок группами, блок группы состоят чанков, чанки заполняются данными, размер чанка обычно 1 Гб для data и 256 Мб для metadata, на больших ФС могут быть больше.

При single каждый чанк каждой блок группы создаётся только на одном девайсе, диск для чанка выбирается с бОльшим свободным местом. При raid0 каждый чанк страйпается между всеми девайсами.

Приоритетов дисков пока нет и в ближайшем будущем не ожидается. Для кеширования рекомендуется использовать bcache.

А если места на дисках одинаково сделано? Я так понимаю сейчас первым идет рамдиск и именно на нем сначала выделяется место и идет запись потому как скорость 1.5Гб/с. при тестировании было (dd dev/zero->/tmp).

Практика показывает, что место сначала выделяется на первом диске, потом на втором, почти сразу но не сразу. Вот бы знать как определить на каком диске реально находится файл. Но пока такой инфы я не нашел. Но судя по скорости записи, все же память в приоритете.

Кстати да, feanor, вы хорошую рекомендацию дали про bbcache. hybrid storage для btrfs пробовали делать, но почему то дело не пошло. Я даже патчи нашел пока искал инфу. На вики написано, что не сделано ничего в этом направлении. bbcache в этом смысле не то же самое, что и linear raid, где диски отсортированы по скорости. Так как это кэш и ему сначала придется узнать что кэшировать, а потом уже начать работать и вообще поддерживать логику кэша. В случае же с простым линейным распределением места, сразу все пишеться в самый первый (и быстрый) диск и всего делов, никакого оверхеда вообще.

В любом случае применять bbcache для tmp это уже слишком...но может под настроение прикручу :)

Посмотрел bcache. Насколько я понял, надо создать бэкдевайс и кэш девайс. Оба они должны быть блочными устройствами и не рекомендуется их создавать поверх других блочных устройств (например loop таким образом не катит). При этом создать кэш в файле нельзя.

Отсюда для решаемой задачки выходит не использовать. Если ramdisk отдать целиком под bcache еще можно, то вот делать отдельный партишен (это как минимум) под бэкдевайс мне не хочется так как изменить размер файла, выделенного как «кусок tmp на hdd» я могу легко, а вот с партишеном возиться уже сложнее.

Так что пока single data single metadata в btrfs подходят лучше всего в рамках данного решения.

Но вот подумать о том, что бы поставить линь на bcache=ssdX+hddX думаю стоит. От этого ssd вполне вероятно проживет дольше просто потому, что стратегия при которой данные пишутся на hdd, а читаются с sdd, постепенно перетекая туда если читаются часто и только...это вполне себе мне нравится.

При этом: bcache + btrfs was not stable with bcache with old kernels but is apparently ok with 3.19+

Оказывается есть linear raid с сортировкой от быстрого диска к более медленному :)

Называется это btier :) Все уже придумано до нас, м-да.

Т.е. Ты нулями заполняешь файл на ФС с включённым сжатием? Офигеть тест!

Это ведь просто тест io, как влияет на процесс сжатие мне по сути все равно. Все дело в том, что задача теста состоит в том что бы только лишь выяснить - память первой работает или диск в режиме single, так что тест адекватный. Так как при тех же условиях когда первым стоит диск, скорость падает в 15 раз.

Ан нет :) Вы правы. Скорость нифига не падает :) Я видать запутался и перепутал все это с raid0 режимом. Сейчас проверил еще раз. От порядка дисков при создании ФС скорость либо вообще, либо почти не зависит в случае заполнения нулями. Развлечения, такие развлечения :) Думаю перепроверить и raid0 режим стоит...но мне лень пока, да и интерес был в том что бы конструкцию собрать и посмотреть будет ли работать (работает отлично), а не тестить насколько быстро я в начале и вообще не хотел :)

Собственно к /dev/zero я пришел когда понял, что /dev/urandom выдает данные со скоростью меньше 50Мб/с и почему-то выдает не запрашиваемое число байт, а сколько ей захотелось (что меня вообще удивило, в среднем где то 32Мб и все). Так что чем еще можно протестировать все это я пока не придумал. Так как при копировании файла откуда то, его надо читать и скорость упрется в это чтение.

upd: выяснилось, что 32МБ он выдает если запросить куски по 1Гб, если куски по 1Мб, выдает сколько надо, но скорость маленькая.

Я теперь отрубил сжатие. И заполнение нулями файла на таком /tmp, происходит со скоростью 962Мб/с. Без сжатия. С сжатием 1.5-1.9Гб/с Но судя по всему все же первой работает память, не может на обычный ssd диск с такой скоростью 4Гб нулей записаться, нет у меня такого здорового кеша что бы в него все это слилось незаметно.

/dev/urandom

Энтропия. И еще зависит от системы он случаем у вас не == /dev/random ?

Да вроде в убунте 16.04 это разные вещи. Во всяком случае ведут себя они по разному...из random вытащить данные еще сложнее :) Но я читал о том как они устроены потому, не удивлен тому, что ведут себя по разному. В конфигах не смотрел одно ли они и то же.

Вообще, bcache поверх loop работать то будет, хоть и не рекомендовано. Сейчас btrfs поверх того же loop работает, так что можно и прикрутить когда-то.

Вот бы знать как определить на каком диске реально находится файл.

В конце июля в linux-btrfs запостили патчсет для btrfs-progs с добавлением двух команд как раз для этого. Правда в btrfs-progs 4.7 он не вошёл, возможно будет в 4.8.

Я тут понял внезапно, что bcache не суммирует место на дисках, в отличие от btier. Так что для данной задачки он все же не подходит и мое решение получше в данном конкретном случае. btier же я не нашел ни в ядре, ни в репах, так что его прикручивать не стану. Таким образом задачка останется в том виде как есть и так работает быстро и без проблем. Единственный косяк, это порядок отмонтирования этого всего. Но так как ФС создается все время снова, то я даже его разрешать не хочу пока.

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