LINUX.ORG.RU
ФорумTalks

Последние секунды жизни btrfs

 ,


1

2

В завершении истории о пропадающих файлах на btrfs.

По ряду причин, я продолжил пользовать эту великолепную ФС на одной рабочей станции c -o compress,nospace_cache.

Итак, постепенно фрагментация нарастала, тормоза усиливались. ls в директории с тысячей файлов уже занимал до секунды, открытие лога gajim - около 10 секунд. И наконец вчера btrfs впервые подала симптомы клинической смерти: no space left on device на полупустом разделе.

>>> df -h
Файловая система          Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/rootfs           13G         9,7G  1,5G           87% /
/dev/mapper/home2           135G          72G   60G           55% /home
>>> sudo btrfs filesystem show
Label: 'rootfs'  uuid: e9becd70-04a7-4de3-abfd-525446c1562b
	Total devices 1 FS bytes used 9.20GB
	devid    1 size 13.00GB used 13.00GB path /dev/dm-2

Label: 'home2'  uuid: 1efa8d6b-a4b9-4c68-abb2-acfd77a86d37
	Total devices 1 FS bytes used 70.93GB
	devid    1 size 134.98GB used 134.98GB path /dev/dm-1

Btrfs Btrfs v0.19

Удаление пары тысяч файлов не помогло, remount помог лишь ненадолго, а пользоваться файлухой дальше фактически невозможно.

Выводы:

1. btrfs умирает за ~2,5 года ежедневного использования.
2. За это время в логах так и не обнаружено ни одной ошибки от драйвера btrfs.
3. Все оставшиеся на ФС файлы можно извлечь пост-мортем.

★★★★★

Ответ на: комментарий от ArtKun

2,5 года назад это была совершенно другая ФС

Она уже была в ядре и вскоре потеряла флаг experimental.

И да, какое ядро?

Мучения закончилось на 3.3.9

shahid ★★★★★
() автор топика
Ответ на: комментарий от Kroz

Багрепорт имеет смысл писать к нужному софту. Но BTRFS - defective-by-design, об этом ещё Шишкин писал в своё время, а я убедился в этом на личном опыте. Т.е. btrfs - это не нужный софт. Поэтому пусть лучше сдохнет по-быстрее.

shahid ★★★★★
() автор топика
Последнее исправление: shahid (всего исправлений: 1)

Концепция комбайнов порочна изначально.

Homura_Akemi
()

/sbin/btrfsck ничего интересного не показывает? Насколько помню он не умеет исправльять, но что то показать должен.

at ★★
()

Тоже замечал всё нарастающие проблемы с Btrfs при включённой компрессии. Без неё уже на новом разделе стабильность и скорость на уровне ext4.

krakatau
()

А есть какой-нибудь наглядный способ измерения фрагментации на этой фс? А то я тут var на нее перенес и мне интересно, в связи с чем возникают тормоза.

malices_gossips ★★★
()
Ответ на: комментарий от shahid

Это не вывод, это констатация факта.

А ошибка «no space left on device». Тебе мейнтейнеры дальше расскажут какие комманды набирать.

Кстати, может у тебя там снапшоты делались какие-нить или ещё что?

true_admin ★★★★★
()

btrfs умирает за ~2,5 года ежедневного использования.

За эти 2.5 года btrfs много «улучшали», то есть подпирали всевозможными костылями. Возможно, что свежие инсталляции и не будут дохнуть так быстро как старые, вопреки быдлоприроде этого поделия. Но уверенным ни в чем быть нельзя: на то оно и defective by design.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от true_admin

мейнтейнеры дальше расскажут какие комманды набирать

Я уже набрал mkfs.reiserfs для исправления проблемы.

может у тебя там снапшоты делались какие-нить или ещё что?

Не, ничего не было. Из нестандартных фич - только сжатие. Свет отрубался пару-тройку раз в год. На home была в основном свалка растущих репозиториев git и mercurial, т.е. тысячи мелких сжимабельных файлов.

shahid ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

Разработчик btrfs - Оракл, глобально и надежно, чо.

Они же вроде сановскийх zfs-иков подпрягали на разработку btrfs, или мне почудилось?

malices_gossips ★★★
()
Ответ на: комментарий от Homura_Akemi

Reiser4 кстати отжила 3 года у меня. Ушел я с неё ибо было лень дальше наблюдать за фрагментацией и патчить/компилять ядро. Так что мнение Шишкина авторитетнее получается)

shahid ★★★★★
() автор топика
Ответ на: комментарий от shahid

Насколько я знаю, все зависит от того, изменился ли за это время disk layout, то есть если отформатировать раздел на ту же ФС сейчас, она может вести себя по-другому. Ну и да, эту штуку можно использовать только с распоследним ядром, туда с каждым обновлением тонны изменений вносят.

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

ArtKun ★★★★★
()
Ответ на: комментарий от Manhunt

Нет, я понимаю, тестеры нужны и все такое.

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

Deleted
()
Ответ на: комментарий от Harald

а бэкап у тебя был?

В некотором смысле был: ценные исходники всегда лежат в нескольких местах. Остальная инфа на разделах ценности не представляла.

shahid ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

Почему не ext4?

На данной рабочей станции в rootfs и home лежат тысячи мелких файлов. На /home - исходники, конфиги и прочая лабуда.

shahid ★★★★★
() автор топика
Ответ на: комментарий от shahid

ибо чинить он не умеет

Я таки видел новость про то, что он научился.

Darth_Revan ★★★★★
()
Ответ на: комментарий от shahid

У Шишкина были несколько странные условия: 659M диск, заполненный 2K фалами это не совсем обычное использование ФС, естественно большую часть занимали метаданные.

at ★★
()
Ответ на: комментарий от at

btrfs позиционировалась ораклом для будущего энтерпрайза, поэтому условия были энтерпрайзные.

659M диск, заполненный 2K фалами

Это может быть:

1. Проект, собранный, вместе с исходниками.
2. lucene-индексы
3. /var/lib/postgres/9.1/data
4. Кеш веб-кравлера-индексатора
5. Содержимое /var/mail
6. ...

shahid ★★★★★
() автор топика
Ответ на: комментарий от at

2.5 года назад никакого fsck.btrfs не было )

shahid ★★★★★
() автор топика
Ответ на: комментарий от malices_gossips

У оракла любимое нынче детище в базе - ASM, с которым LVM отлично справляется. ZFS досталась ораклу «вместе с солярисом» в нагрузку к сановским клиентам, которых они таким образом покупали.

А сан, в свою очередь, начал писать ZFS от безысходности - metatool смотрелся просто ужасно ещё в начале 2000-х годов, а UFS и того страшней была, поэтому клиенты активно покупали всякие веритасы - хотя не особо жаждали такого «счастья», прямо скажем - и в результате смотрели на конкурирующие платформы как более цельные.

В общем, zfs и java - два примера эпичного неправильного позиционирования технологий, btrfs - эпичная попытка повторить неправильно спозиционированную [да ещё и ненужную тут] технологию.

no-dashi ★★★★★
()
Последнее исправление: no-dashi (всего исправлений: 1)
Ответ на: комментарий от at

У Шишкина были несколько странные условия: 659M диск, заполненный 2K фалами это не совсем обычное использование ФС, естественно большую часть занимали метаданные.

Ты не понял сути проблемы, которую Шишкин продемонстрировал тогда. Дело не в том, что метаданные занимают в N раз больше места, чем данные — а в том, что по мере эксплуатации ФС это число N может неограниченно увеличиваться. Для наглядности, теоретически, на 1 байт полезных данных может приходиться 1 терабайт места, занятого метаданными.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)

а у меня недавно винт умер (500гб 4года)

посоны не форматируйте винт в бтрфс

uin ★★★
()
Ответ на: комментарий от Manhunt

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

А дома на /home использую ext4. Вполне ок.

shahid ★★★★★
() автор топика
Последнее исправление: shahid (всего исправлений: 2)
Ответ на: комментарий от shahid

btrfs позиционировалась ораклом для будущего энтерпрайза, поэтому условия были энтерпрайзные.

Поэтому меня интересовало поведение фс на больших разделах, хотябы пару ТБ.

У меня бтр сдох примерно через пол года, но это оборудование. Я специально использовал сбойный рейд-контролер.

3. /var/lib/postgres/9.1/data

Использование COW фс для базы данных это не лучший выбор ;) Хотя хотелось бы посмотреть на результаты тестирования btrfs vs zfs допустим под ораклом. Т.е. относительно большие файлы, постоянно перезаписываемые. С остальным согласен.

at ★★
()
Ответ на: комментарий от Manhunt

Это я понял. Меня несколько насторожили условия тестирования. Всегда можно подобрать условия, где одна фс сольет другой. К тому же Шишкин лицо заинтересованное. В его объективности я не сомневаюсь, но, все таки, это не совсем независимые тесты.

at ★★
()

За это время в логах так и не обнаружено ни одной ошибки от драйвера btrfs.

Чувак, признайся - ведь логи у тебя тоже лежали на той же btrfs? Вот и нет в них ошибок :-)

no-dashi ★★★★★
()
Ответ на: комментарий от Manhunt

ext4 хранит журнал в начале диска и при активной записи тысяч мелких файлов начинает его активно дрочить и двигать головку винта. Когда число файлов идет на миллионы, то скорость записи падает до десятка (!!!) файлов в секунду. У btrfs и zfs нет такого недостатка.

Reset ★★★★★
()
Ответ на: комментарий от no-dashi

Логи были в /var, а там только рейзер ибо pacman и abs создают-удаляют файлы тысячами.

shahid ★★★★★
() автор топика

Шо, ужэ?!! Не успела зарелизиться по-нормальному и фтопку?
Хорошая новость. Нормальные люди юзают ext4.

Pakostnik ★★★
()
Ответ на: комментарий от Reset

Откуда вы все такие специфические use-кейсы и проблемы берете?
И дома, и на работе до сих пор ext3 используется - и ничего, скорость устраивает, данные не теряются.

kovrik ★★★★★
()
Ответ на: комментарий от Kroz

Компрессия

Зачем? Нигде оно не работает нормально, даже в оттестированной вдоль и поперёк NTFS.

снапшоты

Зачем это на уровне ФС?

отсутствие инодов

Слабый аргумент.

Homura_Akemi
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.