Комментарии 59
НЛО прилетело и опубликовало эту надпись здесь
Аналогично подумал, когда прочитал этот абзац. Зачем рассказывать о ФС, которые способна необратимо потерять информацию из-за собственных багов. Может конечно это привлечет кого-нибудь для помощи в разработке, но с такой ситуацией пользоваться ей вообще желания нет.
Полагаю, что заверения о стабильности взялись не с потолка. Как минимум, проблемы возникают точно не в стандартных сценариях. В статье хотелось максимально честно отразить обе стороны btrfs. Возможно, стоило указать на минусы ближе к концу статьи — спасибо за фидбек, учтем в будущем. Теперь про спор на тему «надо ли ею пользоваться». Увы, но в общем случае он не разрешим — у каждого частного случая свои задачи и требования. Другое дело узнать что такая ФС, в принципе, существует и познакомиться с подходом в организации хранения и распространения управления данными, думаю, многим интересно. Ну и хочу отметить что словами «зачем… если ...» можно похоронить любой молодой проект.
НЛО прилетело и опубликовало эту надпись здесь
Чтобы не потерять данные делайте Veeam бэкапы.
«Рубанули хост с виртуалками, после чего две навсегда ушли в аут» — это насколько «нестандартно»?
Пока утилита восстановления, извините, сегфолтится при попытке такое починить, Btrfs получает официальный бейдж БАРАХЛО-ФС.
Пока утилита восстановления, извините, сегфолтится при попытке такое починить, Btrfs получает официальный бейдж БАРАХЛО-ФС.
Судя по официальной вики, наибольшие шансы потери данных в режимах raid56, они официально нестабильны. Остальное достаточно стабильно для production. Для raid56 я бы рекомендовал raidz/raidz2 в ZFS, личный опыт строго положительный.
Почему же избыточно? Как минимум есть те кому интересно узнать что в linux мире существует не только extfs и swap. Что есть иные подходы к организации данных на носителях.
mdadm, lvm, вот это всё. А сверху хоть черта лысого в качестве ФС можно сделать.
ИМХО в данном случае не стоит валить всё в одну кучу. Управление томами отдельно, ФС отдельно.
ИМХО в данном случае не стоит валить всё в одну кучу. Управление томами отдельно, ФС отдельно.
По такому принципу все статьи про CEPH тоже избыточны. А их нынче развелось как-то подозительно не мало…
Второй год / живет на btrfs и как-то ни разу еще не сталкивался.
Инкрементальные бекапы на другой носитель решают 99.999% таких проблем! А делаются они быстро и легко. Кто не делает бекапы, может потерять данные на любой системе. Для меня преимущества и удобство BTRFS перевешивают «возможные» потери данных. Восстановление из резервной копии тоже как два пальца! Я так даже устанавливал систему в виртуалке, настраивал всё что нужно и накатывал её простым переносом как резервную копию (с правкой fstab)
Совсем недавно она перешла из статуса «еще не пригодно» в статус «стабильна».
Скорее из статуса «еще не пригодно» в статус «уже не пригодно». RH задепрекейтила Btrfs и обещает совсем дропнуть в будущем.
На замену btrfs RH пообещала пользователям выпустить аналог под названием Stratis, позаимствовав многие концепты у btrfs и zfs. Отлично же — будут аналоги, будет конкуренция, будет развитие. Может, это и подтолкнет btrfs к качественному скачку в стабильности.
Может, это и подтолкнет btrfs к качественному скачку в стабильности.
Сомнительно, разработчики уйдут, пользовательская база станет меньше, с чего вдруг должен возникнуть этот скачок. Если за предыдущие годы, пока была поддержка со стороны RH, и в Suse тоже как дефолтная система использовалась, так и не довели до ума, то теперь шансов еще меньше.
Что касается Stratis, посмотрим, конечно, что из этого получится. Но всё таки это не новая ФС, это по факту dev-mapper + XFS.
Red Hat её особо и не разрабатывала последние годы, Её активно разрабатывает SUSE как минимум с 2014-го.
git shortlog -sne -- fs/btrfs/
929 Chris Mason <chris.mason@oracle.com>
655 David Sterba <dsterba@suse.com>
394 Linus Torvalds <torvalds@linux-foundation.org>
392 Nikolay Borisov <nborisov@suse.com>
357 Filipe Manana <fdmanana@suse.com>
312 Liu Bo <bo.li.liu@oracle.com>
312 Miao Xie <miaox@cn.fujitsu.com>
303 Josef Bacik <josef@redhat.com>
265 Josef Bacik <jbacik@fusionio.com>
208 Anand Jain <anand.jain@oracle.com>
205 David Sterba <dsterba@suse.cz>
155 Qu Wenruo <wqu@suse.com>
147 Jeff Mahoney <jeffm@suse.com>
147 Qu Wenruo <quwenruo@cn.fujitsu.com>
142 Josef Bacik <jbacik@fb.com>
128 Al Viro <viro@zeniv.linux.org.uk>
113 Chris Mason <clm@fb.com>
105 Stefan Behrens <sbehrens@giantdisaster.de>
А что сейчас в тренде из стабильного и с разными возможностями, раз уж BTRFS не стабильная?
Под данные критерии более-менее подходит ZFS (не сказал бы что в тренде). На хабре про неё есть неплохие вводные статьи.
ZFS похоже что наилучший выбор сейчас. Набор функций примерно такой же, сама ФС проверена временем и стабильна. Есть правда и минусы:
— в отличие от BTRFS использование в контейнерах ограничено: нельзя внутри контейнера создать или удалить вложенный volume — в BTRFS можно;
— недавний конфликт с разработчиками ядра из-за несовместимой лицензии, из-за чего из ветки 5.х выпилили необходимые для ZFS функции, из-за чего производительность снизится. однако это проблему скорее всего обойдут, если не уже обошли, реализацией этих функций на стороне ZFS.
— в отличие от BTRFS использование в контейнерах ограничено: нельзя внутри контейнера создать или удалить вложенный volume — в BTRFS можно;
— недавний конфликт с разработчиками ядра из-за несовместимой лицензии, из-за чего из ветки 5.х выпилили необходимые для ZFS функции, из-за чего производительность снизится. однако это проблему скорее всего обойдут, если не уже обошли, реализацией этих функций на стороне ZFS.
Молодец Леха, так держать) отличная статья.
Замечу, что если попытаться удалить сабвольюм средствами файлового менеджера или утилиты rm, то операция завершится с ошибкой operation not permitted (операция не разрешена).
Замечу, что начиная с какой-то там версии ядра это уже не так
BTRFS использую для личного бекапа (важной для меня части оного) уже 4 года. Около 2 Тб и более миллиона файлов. На разделе, зашифрованном LUKS. RAID на уровне ФС не использую, т.к. «внизу» аппаратный RAID-контроллер.
BTRFS выбрана прежде всего ради удобных снапшотов. Все файлы синхронизируются с различными облаками и нужна была версионность, чтобы при необходимости откатить нежелательные правки / случаи порчи данных, которые благодаря облачной синхронизации моментально расползаются на все машины. А ZFS на момент выбора не прокатывала из-за её аппетита к RAM.
Снапшоты делаются с помощью snapper. Раз в месяц запускается btrfs scrub, проверяющий те самые контрольные суммы, которые в статье упомянуты (а вот scrub почему-то нет). Это весомый дополнительный бонус, гарантия от случайного повреждения данных, каковое на таких объёмах весьма вероятно.
Поломал я её до состояния «всё снести и выкачать из облака заново» один раз, и то по своему собственному невежеству, т.к. в лоб запустил btrfsck, которую вообще запускать не надо. Потом почитал про то, как надо, и больше так не буду (в том случае надо было сделать btrfs-zero-log)
В общем, выбором доволен. Если бы выбирал с нуля — сейчас, когда на домашнем сервере уже 96 Гб RAM, а не 8 Гб, как было 4 года назад, может, выбрал бы и ZFS. Но повода менять уже настроенное и работающее решение не вижу.
Но да, у меня это как минимум третья, а для части данных и четвёртая копия, так что даже самый катастрофический сценарий к безвозвратной потере данных не приводит.
BTRFS выбрана прежде всего ради удобных снапшотов. Все файлы синхронизируются с различными облаками и нужна была версионность, чтобы при необходимости откатить нежелательные правки / случаи порчи данных, которые благодаря облачной синхронизации моментально расползаются на все машины. А ZFS на момент выбора не прокатывала из-за её аппетита к RAM.
Снапшоты делаются с помощью snapper. Раз в месяц запускается btrfs scrub, проверяющий те самые контрольные суммы, которые в статье упомянуты (а вот scrub почему-то нет). Это весомый дополнительный бонус, гарантия от случайного повреждения данных, каковое на таких объёмах весьма вероятно.
Поломал я её до состояния «всё снести и выкачать из облака заново» один раз, и то по своему собственному невежеству, т.к. в лоб запустил btrfsck, которую вообще запускать не надо. Потом почитал про то, как надо, и больше так не буду (в том случае надо было сделать btrfs-zero-log)
В общем, выбором доволен. Если бы выбирал с нуля — сейчас, когда на домашнем сервере уже 96 Гб RAM, а не 8 Гб, как было 4 года назад, может, выбрал бы и ZFS. Но повода менять уже настроенное и работающее решение не вижу.
Но да, у меня это как минимум третья, а для части данных и четвёртая копия, так что даже самый катастрофический сценарий к безвозвратной потере данных не приводит.
Очень странно, 2 Тб это копейки и для ZFS достаточно 2-3Гб памяти. Главное не включать дедупликацию — это слишком неоднозначная и хитрая фича, которая стреляет позже. В принципе, при небольшом тюнинге 120Тб пулы вполне работают с 64Гб памяти в весьма нагруженном режиме. Правда, на фре…
Дурацкий вопрос, а как оно будет жить с штатным софтрейдом, раз со взрослыми рейдами(5,6) у неё не очень?
Если на btrfs закончилось место, то даже удаление какого-либо файла может вызывать ошибку «No space left on device». Для решения рекомендуется подключить к btrfs временный накопитель размерами желательно не менее 1GB. После чего произвести чистку данных. Затем удалить временный накопитель.
Как-то приходилось скачивать большие файлы, а потом их удалять. Первый раз, увидел такую картину, что половина диска свободна, а записать новый файл не могу — место закончилось. Трюк с подключением временного внешнего диска нашел не сразу, но он много раз спасал, когда я забывал вовремя балансировку запускать. Может сейчас получше с ней, но уже года 2 как ext4 обратно перешел.
Можно ли слово «subvolume» перевести как, например, подраздел?
НЛО прилетело и опубликовало эту надпись здесь
Мой выбор в сторону англицизма основывается на том что subvolume — специфичный объект и достоин быть англицизмом для акцентирования этого. К тому же он не относится ни к томам ни к разделам.
Хотелось бы услышать какой вариант для Вас наиболее предпочтителен. Обоснование обязательно.
Хотелось бы услышать какой вариант для Вас наиболее предпочтителен. Обоснование обязательно.
НЛО прилетело и опубликовало эту надпись здесь
Volume — это том. Sub-volume — это подтом. Сабвольюм — это для обычного человека непонятно что. И по своей структуре sub-volume как раз является отдельным томом внутри контейнера. На Btrfs, может быть, это не так очевидно, но на APFS каждый подтом можно рассматривать как независимую файловую систему (если не учитывать изобретенные ими фирмлинки).
Использую Synology c btrfs и Veeam Agent for Windows. Файл полной резервной копии постоянно растет в объеме, занимая на томе больше месте, чем реально занимает, т.е. например, объем файла резервной копии 150Гб, а на диске занимает 200Гб. Если файл скопировать, но занимаемое место на диске станет 150Гб. Veeam Agent for Windows не замечает замену, этим (скопированным) файлом, файла полной резервной копии. Как с этим можно побороться (постоянным ростом файла полной резервной копии)?
> btrfs subvolume snapshot create /path/to/subvol /path/to/snapshot -r
А синтаксис немного другой
# btrfs subvolume snapshot -r /path/to/subvol /path/to/snapshot
# btrfs --version
btrfs-progs v4.9.1
А синтаксис немного другой
# btrfs subvolume snapshot -r /path/to/subvol /path/to/snapshot
# btrfs --version
btrfs-progs v4.9.1
Странно, но не работает ключ --resizefs
# lvextend -L16G centos/dev --resizefs
fsadm: Filesystem "btrfs" on device "/dev/mapper/centos-dev" is not supported by this tool.
Filesystem check failed.Взамен приходится делать
# lvextend -L16G centos/dev
# btrfs filesystem resize max /mnt/dev
Если на btrfs закончилось место, то даже удаление какого-либо файла может вызывать ошибку «No space left on device». Для решения рекомендуется подключить к btrfs временный накопитель размерами желательно не менее 1GB. После чего произвести чистку данных. Затем удалить временный накопитель.
Пробовал несколько раз — все прекрасно удаляется (спасибо системному резерву). Даже создать снапшот можно.
Большое спасибо за ликбез! Сейчас хочу начать пользоваться UNRAID взамен виндового сервера, а т.к. в никсах совсем ноль, то приходится гуглить, какую ФС выбрать для хранения данных XFS или BTRFS. Ваша статья дала представление о второй. Правда в отличие от NTFS, которую может восстановить полно софта, то не ясно какую из этих двух брать на случай сбоев с восстановлением данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BTRFS для самых маленьких