Авторские статьи об OpenSource

Btrfs в Ubuntu.


Очень давно начались мои ранние эксперименты и тесты новой файловой системы Btrfs. Не всё было радужно и весело, но время шло и Btrfs хорошела. На свой первый SSD OCZ Onyx OCZSSD2-1ONX32G решился установить именно Btrfs, ради её умения работать с твердотельными дисками через параметр -o ssd, но скажу честно, что отказался в дальнейшем в пользу ext4 без журнала. Но сейчас история не моя, а сотрудника Canonical Алана Поупа (Alan Pope), который описывает своё домашнее приключение с Btrfs, поэтому речь пойдёт от его лица.

DroboНекоторое время назад, дома мне понадобилось дополнительное место для хранения резервных копий и медиа файлов. Хотелось аккуратного решения, которое будет расти с моими требованиями. Очень не хотелось бы кучи жёстких дисков, висящих на USB портах. В конечном счёте был куплен Drobo с парой новых дисков и подключено всё через USB. Надо сказать, что проработало это добрую пару лет, но я не был доволен полностью данным решением. По разным причинам (плохая родная linux поддержка, медленное устройство, трата времени на обновление прошивки устройства) в конечном итоге решено было избавиться от Drobo.

Мои требования просты, хотя Drobo им противоречил:

  • NAS (Network Attached Storage) должен легко и динамически уметь расширяться (grow) и уменьшаться (shrink).
  • На моём столе не должно быть огромного и уродливого устройства.
  • Не прожорливое в плане потребления электроэнергии устройство.
  • Лёгкость в настройки и в дальнейшем администрировании.
  • Возможность запуска дополнительного ПО с устройства: типа DNS сервера, DynDNS демона, медиа сервер.
  • Запуск Ubuntu.

HP MicroserverПримерно в этом время стал доступен HP Microserver по приемлемой цене в маленьком форм-факторе, который, как казалось, удовлетворяет моим требованиям. После покупки жёсткие диски перекочевали из Drobo в HP Microserver и были отформатированы. Сначала была задумка использовать Linux MD RAID, но вскоре выяснилось, что легко увеличивать и уменьшать массив я не смогу.

Мой друг Hugo Mills все уши прожужжал о файловой системе Btrfs (B-tree FS) и захотелось попробовать её. Он мне пел про её сжатие, изменение размеров на лету, родные средства создания RAID, восстановление после ошибок, снимки и так далее. Способность файловой системы легко расширяться (grow) и уменьшаться (shrink) была наиболее важна для меня. Но я слышал страшные истории про Btrfs и что она ненадёжна и не имеет стабильной версии до сих пор. Но мой домашний сервер не хранит ничего из того, что можно достать в другом месте и мне было любопытно попробовать. Если все будут избегать её, потому что она нестабильная, то кто будет искать ошибки, чтобы сделать её стабильной?

В апреле 2012 было:
root@homeserver:~# btrfs fi df /srv
Data, RAID1: total=1.08TB, used=1.07TB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=164.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=2.75GB, used=1.77GB
Metadata: total=8.00MB, used=0.00

root@homeserver:~# btrfs fi show
Label: none uuid: 981b32ab-95ad-4873-8f14-820748a18ac7
Total devices 4 FS bytes used 1.08TB
devid 4 size 1.82TB used 0.00 path /dev/sda
devid 1 size 1.82TB used 736.27GB path /dev/sdc
devid 2 size 1.82TB used 736.76GB path /dev/sdd
devid 3 size 1.82TB used 736.51GB path /dev/sde

Создание btrfs раздела из 3 дисков было плёвое дело, добавление четвёртого диска (когда он был доставлен) так же было лёгким. Хорошая вики проекта btrfs детально описывает использование btrfs при работе со множеством дисков.

Используя fdisk и mkfs.btrfs и был создан RAID1-подобный раздел: mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc /dev/sdd /dev/sde

RAID1 не в классическом, а в терминах btrfs, следует понимать так: копия важных данных существует на двух дисках в массиве и не важно сколько в массиве дисков. То есть в классическом RAID1 если взять 4 диска по 2 Тб, то получится массив 2 Тб с 4 копиями данных. Btrfs даст 4 Тб с 2 копиями данных, но можно использовать разные по размерам устройства и даже использовать нечётное количество дисков.

В /etc/fstab добавлено /dev/sdc /srv btrfs noatime,nodiratime 0 0

Sans Digital TowerRAID TR8M+B 8 Bay eSATA ArrayИ следующие пару месяцев было всё довольно гладко. Но с нехваткой места было решено купить Sans Digital TowerRAID TR8M+B 8 Bay eSATA Array и через PCIe eSATA добавлен к моему HP Microserver. Стало легко добавлять диски.

Иногда загрузка занимала много времени, так как btrfs.fsck не вовремя принимался за проверку. Проверку при загрузке я убрал. Вскоре я, неуклюжий чурбан, обнаружил, что eSATA кабель легко выбить из гнезда. Но всё было не так страшно. Потери данных не было, несмотря на то, что 8 из 12 дисков, подключённые к серверу, пропали на время. После перезагрузки компьютера всё вернулось на круги своя. В ноябре 2012 года дружище Hugo напомнил мне, чтобы я запустил процедуру scrub, при котором осуществляется чтение и проверка всех данных и метаданных с целью выявления ошибок и нарушений целостности в файловой системе Btrfs.

Я проверил статус и, ой, 6 месяцев не запускалась проверка.
$ sudo btrfs scrub status /srv
scrub started at Mon Apr 30 18:19:15 2012 and finished after 19652 seconds
total bytes scrubbed: 6.42TB with 0 errors

Самое время для scrub!

$ sudo btrfs scrub start /srv
scrub started on /srv, fsid 981b32ab-95ad-4873-8f14-820748a18ac7 (pid=30510)

$ sudo btrfs scrub status /srv
scrub status for 981b32ab-95ad-4873-8f14-820748a18ac7
scrub started at Fri Nov 16 09:35:53 2012, running for 220 seconds
total bytes scrubbed: 68.70GB with 0 errors

Совсем недавно, один из дисков внутри HP Microserver ушёл в оффлайн. Я подумал грешным делом, что он сдох. Оказалось, что он плохо сидел в сервере. Я вытащил все диски и заново, с усилием, вставил их обратно. Запустил scrub - всё отлично, потерь нет!

Около месяца назад, мой сервер перестал отвечать. Я перезагрузил его и вроде стало всё нормально, но, позже, после запуска scrub, сервер перестал отвечать снова. Я подумал что всё - кабзец аппаратуре. Пожаловался Hugo и тот вспомнил, что был такой баг в btrfs, когда операция scrub сжирает всю память при своей работе. Патч был доступен для Linux Kernel 3.11-rc6 и я уже было готов компилить своё ядро, но вспомнил, что это не нужно, так как любимые коллеги из команды Ubuntu Kernel уже всё сделали. Схватил их готовый deb с новым ядром и накатил его в систему. Теперь btrfs scrub не выжирает память. Ура!

Уроки что я вынес:

  • Btrfs очень проста в работе с ней.
  • Нужно использовать современные ядра linux. На момент написания статьи использовалось 3.11.0-031100rc6-generic.
  • Лучше не юзать fsck.
  • Использовать последние версии btrfs tools.
  • При покупке новых дисков легко расширяться - btrfs device add /dev/sdz /srv
  • Выкинуть диск из массива просто - btrfs device delete /dev/sdz /srv
  • Лучше юзать scrub регулярно. В свой /etc/crontab внёс 0 1 15 * * /sbin/btrfs scrub start /srv
  • Люди на канале #btrfs IRC freenode очень доброжелательны.
  • Если диск якобы умер, как у меня недотёпы выпал кабель eSATA, не паникуйте. Читайте вики и спросите в IRC.
  • В любой момент всё может пойти не так и можно потерять всё. Со мной этого ещё не произошло, уффф.
  • Я люблю btrfs.

От себя лично хочется поблагодарить Алана и его друга Hugo Mills за разъяснение разницы между классическим RAID1 и btrfs -m raid1 -d raid1. Hugo так же рассказал, что в случае проблем он бы советовал использовать btrfsck в последнюю очередь.

Восстановление btrfs.

В идеале, если это технически возможно, вначале нужно сделать копию файловой системы - btrfs-image -c9 -t4.

Если предположить, что диск не сломался физически, то в первую очередь лучше использовать -o recovery. Если это не поможет, то смотрите dmesg на предмет ошибок с деревом журнала (log tree) и, если он повреждён, то лучше использовать btrfs-zero-log.

Если у вас редкая проблема с деревом чанков (chunk tree), например пишется о can't map address, то поможет chunk-recover.

Btrfsck стоит пробовать в последнюю очередь с ключами -s1, -s2, -s3. Если ключи помогут, то btrfs-select-super сможет заменить суперблок на работоспособный. Если ключи не помогают, то пробуйте btrfsck --repair. Может пригодиться btrfsck --repair --init-extent-tree если повреждено дерево экстентов (extent tree). Если повреждены контрольные суммы, то используйте параметр --init-csum-tree.

Дополнительные материалы:
Ускорение файловой системы Btrfs.
Установка Ubuntu Linux на SSD с Btrfs.

    Twitter   


Разделы

Главная
Новости
Ворох бумаг
Видео Linux
Игры в Linux
Безопасность
Статьи о FreeBSD
Статьи об Ubuntu
Статьи о Snappy
Статьи об Ubuntu Phone
Статьи о Kubuntu
Статьи о Xubuntu
Статьи о Lubuntu
Статьи об Open Source
Карта сайта

Лучшее на сайте:

1С под Linux.   Ускорение Ubuntu.   21 пример iptables.   Цикл статей о Ceph.   Убунту в дикой среде.   Ubuntu Linux на SSD.   Ubuntu для блондинок.   Поддержка железа в Linux.   BTSync на службе у админа.   Андроид программы в Ubuntu.   Прокидывание портов для p2p.   Анти СПАМ в Postfix.  



Круги Гугл Ада.


Группа поддержки