Очень давно начались мои ранние эксперименты и тесты новой файловой системы Btrfs. Не всё было радужно и весело, но время шло и Btrfs хорошела. На свой первый SSD OCZ Onyx OCZSSD2-1ONX32G решился установить именно Btrfs, ради её умения работать с твердотельными дисками через параметр -o ssd, но скажу честно, что отказался в дальнейшем в пользу ext4 без журнала. Но сейчас история не моя, а сотрудника Canonical Алана Поупа (Alan Pope), который описывает своё домашнее приключение с Btrfs, поэтому речь пойдёт от его лица.
Некоторое время назад, дома мне понадобилось дополнительное место для хранения резервных копий и медиа файлов. Хотелось аккуратного решения, которое будет расти с моими требованиями. Очень не хотелось бы кучи жёстких дисков, висящих на USB портах. В конечном счёте был куплен Drobo с парой новых дисков и подключено всё через USB. Надо сказать, что проработало это добрую пару лет, но я не был доволен полностью данным решением. По разным причинам (плохая родная linux поддержка, медленное устройство, трата времени на обновление прошивки устройства) в конечном итоге решено было избавиться от Drobo.
Мои требования просты, хотя Drobo им противоречил:
- NAS (Network Attached Storage) должен легко и динамически уметь расширяться (grow) и уменьшаться (shrink).
- На моём столе не должно быть огромного и уродливого устройства.
- Не прожорливое в плане потребления электроэнергии устройство.
- Лёгкость в настройки и в дальнейшем администрировании.
- Возможность запуска дополнительного ПО с устройства: типа DNS сервера, DynDNS демона, медиа сервер.
- Запуск Ubuntu.
Примерно в этом время стал доступен 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 и через 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.
Немає коментарів:
Дописати коментар