razum2um — Btrfs пускает корни на "корне"

И вроде бы о ней много писали...

И вошла она в ядро с помпой...

И все-таки хорошего обзора, показывающего, что автор реально пользует фичи, а не цитирует ман/вики - не увидел.

Btrfs.


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

По порядку.


Заявлена поддержка Multiple Devices, с чем она на первый взгляд хорошо справилась. Зайдя с бекапа системы, я снес старый корень на raid0 с двумя дисками и сначала попытался сделать все по-человечески.

mkfs.btrfs -d raid0 -m raid0 /dev/sda2 /dev/sdb2 /dev/sdc2


(Да, у меня три физических жеских и я решился раскинуть рейд0 данных (параметр -d raid0) и метаданных (параметр -m raid0) на всех. Кстати, результат налицо:

hdparm -t гласит

для одного раздела:
Timing buffered disk reads:  290 MB in  3.01 seconds =  96.22 MB/sec

для двух (raid0):
Timing buffered disk reads:  456 MB in  3.00 seconds = 152.00 MB/sec

для трех (raid0):
Timing buffered disk reads:  690 MB in  3.00 seconds = 229.65 MB/sec

(по одному разделу на диск)


Впрочем даже если отвлечься от попугаев, на рабочей (в конце концов) машине на глаз быстрее грузятся и ООо (бинарный) и FF (собраный) и вообще
приятней... На отказоустойчивость корня я, очевидно, забил.


В общем, раскинув пространство на 3 диска, и скопировав обратно корень (cp -ax / /mnt/) и /dev/null,
/dev/console (не удивляйтесь, если без них ничего не загрузится), попытался загрузиться на этот монстр, подумав мельком, что нечисто это: в строке kernel строке grub`а
указывать только root=/dev/sda2. Но факт фактом, после копирования, новая система монтировалась по любому диску...


Конечно.

Нихрена не загрузилось. Залез опять на бекап-систему, попытался примонтировать свежий корень.

Не тут-то было! Классический wrong type. Проняло нас (корень и меня) только после btrfsctl -a, - своеобразный autodetect для btrfs, раскинутой по Multiple Devices. Стало ясно, что простого решения нет: во время загрузки она же должна отрабатывать перед монтированием корня. А откуда, если она сам на корне?! Ответ один - initrd. И ясно, что тупой-дефолтный initrd (после genkernel --mdadm --lvm --install all) не поможет этого.


Попытался "прокачать" его:

"раскатал" образ
mkdir init; cd init

gzip -dc /boot/initramfs-genkernel-x86_64-2.6.31 | cpio -id
теперь посмотрел, что
ldd /sbin/btrfsctl
linux-vdso.so.1 =>  (0x00007fff653ff000)

libuuid.so.1 => /lib/libuuid.so.1 (0x00007fb65a9ca000)

libc.so.6 => /lib/libc.so.6 (0x00007fb65a675000)

/lib64/ld-linux-x86-64.so.2 (0x00007fb65abcf000)

libc.so, ld-linux-x86-64.so, libuuid.so,  btrfsctl скопировал в соотв. места распакованного initramfs
"закатал" образ заново
find ./ | cpio -H newc -o >
/tmp/initramfs-genkernel-x86_64-2.6.31

cd /tmp; gzip -9 initramfs-genkernel-x86_64-2.6.31; cp
initramfs-genkernel-x86_64-2.6.31.gz /boot

Загрузился, оно, ясно не нашло корня и выкинуло в sh. btrfsctl -a
ругнулся на отсутствие /dev/btrfs-control, сбегал на живую систему, понял, что надо mknod /dev/btrfs-control c 10 62


Опять загрузился, btrfsctl -a страшно заругался на кучу файлов в /dev, мол, can't read и виснет.

Опять
сбегал на живую систему и попробовал собрать sys-fs/btrfs-progs с ROOT=init (место, куда распаковал initrd). Сжал, установил initrd опять - все равно ругается на кучу файлов в /dev, мол, can't read и опять-таки виснет.


Надоело.

Сделал
mdadm --create /dev/md2 --level=0 --raid-devices=3
/dev/sd2


и тупо отформатировал /dev/md2. И еще помучился, пока не вспомнил, что для моего способа загрузки (монолит, без initrd) ВСЕ составляющие рейд разделы должны быть промаркированы типом "fd". (fdisk, команда t, выбираем номер раздела, вбиваем fd, сохраняем (w))


Загрузилось. Приятно удивила скорость загрузки некоторых вещей даже по сравнению с прошлым 2х дисковым корнем. (Цифры см. выше).

Пришло время пользовать удобства.

Подразделы.Тренируемся на кошках (sdc4 - тестовый раздел в btrfs):
mkfs.btrfs /dev/sdc4
mount /dev/sdc4 /mnt/temp/
cd /mnt/temp/                        
# Очень важно перейти на раздел! Иначе не получится
echo 'new fs' > new-fs.txt      
# Тестовый файл
btrfsctl -s subvol .                  
#Если вместо точки - полный путь, то получите ioctl:: Invalid argument
# для этого и надо cd. subvol- имя подраздела на ваш вкус.
# (Лучше латиницей и без пробелов)
ls                                            
# Проверьте! subvol - папка, содержащая new-fs.txt с тем же содержимым,
# что и new-fs.txt в корне!
echo 'new subvol' > subvol/new-fs.txt    
# Перетираем тестовый файл в осн. дереве
cd; umount /mnt/temp

Теперь самое интересное: монтируя sdc4 с разным параметром subvol, кажется, что монтируем разные разделы!

mount -o subvol=subvol /dev/sdc4 /mnt/temp/    
# subvol - понятно, имя подключаемого подраздела
cat /mnt/temp/new-fs.txt           
# видим "new subvol"

umount /mnt/temp
mount -o subvol=. /dev/sdc4 /mnt/temp/        
# Точка - имя "главного" тома, с которого мы сняли копию
cat /mnt/temp/new-fs.txt             
# видим "new fs"

# И ура! Начиная с ядра 2.6.32 можно удалять подразделы и снапшоты моментально!
btrfsctl -D subvol /mnt/temp

Схема устройства:

Видно, что помимо самих файлов, есть куча служебных данных, так что при достижении 75% заполнения раздела данными, он уже будет полон, но меня это мало волнует (пока 44%). Минималисты: осторожнее - "df -h" врет!Делаем операцию на себе:
cd /
btrfsctl -s backup .

Повторяю: операция мгновенна и места (сразу) не отнимает
Теперь на "главном" томе я обновил portage, перезагрузился на снапшот backup,
нашел portage старой версии (еще бы :), обновил udev и с ним два конфига. Перезагрузился обратно в главный - нашел их нетронутыми.

Вы даже не представляете, насколько такое положение дел может обрадовать гентушника :)
Не работает система после обновления? - Перезагрузился на старую!Пара слов о grub.conf:
Строка kernel должна выглядеть примерно так:

kernel /boot/2.6.33 root=/dev/md2 rootfstype=btrfs rootflags=subvol=.

ну и потом vga= (разрешение фреймбуфера), video= (драйвер фреймбуфера), elevator= (I/O планировщик) по вкусу. Т.е. как у вас и было
rootfstype=btrfs предпочтительно указывать даже если вы не играетесь снапшотами. Точка - имя "главного" тома, с которого можно увидеть backup в корне и chroot`нуться в него.
Из rootflags=subvol=backup увидеть "главный" том в корне НЕЛЬЗЯ. Только
mount -o subvol=.
UPD
Есть приятная фича онлайн-дефрагментации btrfsctl -d <путь к файлу или каталогу>
Сделал на корне.
Разницы не заметил, хотя использую фс около 5 месяцев.
Опции монтирования и тесты
Тесты проводились на [email protected], 3Gb, 3xSATA2 под raid0
дерево portage (165M) - распакованный архив portage.tar.bz2
file (1G) готовился так: dd if=/dev/urandom of=file bs=8M count=128

/etc/fstab: defaults (т.е. relatime):

$ time cp -R portage portage2
real    0m15.551s

$ time rm -rf portage2
real    0m10.373s

$ time cp file file2
real    0m9.435s

/etc/fstab: noatime,nodatasum,compress:

$ time cp -R portage portage2
real   0m8.113s

$ time rm -rf portage2
real   0m9.025s

$ time cp file file2
real   0m9.218s
Видно, что включение noatime,nodatasum,compress положительно сказывается на быстродействии везде, но незначительно, кроме как на копировании - почти в 2(!) раза быстрее - портажа. Отказоустойчивость при nodatasum, ясно снижается. И последнее предупреждение.
Фс в активной разработке, и не позволительно ставить старые версии, имхо. Смотрите чейнджлог и ставьте из гита. Тем более, что в генту со всякими live-прогами меньше всего проблем с их обновлением ;)

Статьи Федорчука по теме, в хронологическом порядке: 
Знакомство с btrfs,
Btrfs: поговорим о конверсии,
Про улучшения в
0.19 + тесты

UPD
Про фичи btrfs (на анлийском), где кстати утверждается выигрыщ в производительности против ext3/4 из-за особого поведения при fsync()



PS

Желания и времени тестировать (т.е. реально пожить) на корню всякие разные фс сейчас, к сожалению, нет.

Если у кого есть идеи по поводу синтетического теста на свободной партиции - предлагайте.