Долгое монтирование btrfs раздела.

Задал вопрос в #btrfs, пока что не знаю ответа.

Попробуй дважды смонтировать том с -o space_cache=v2 (в смысле размонтировать-смонтировать-размонтировать и так два раза) и замерить время второго монтирования.

Так?

# time mount -o space_cache=v2 /dev/sdc1 /mnt/.transmission 
real	0m43.177s
user	0m0.001s
sys	0m0.429s

# time umount /mnt/.transmission 
real	0m0.114s
user	0m0.000s
sys	0m0.015s

# time mount -o space_cache=v2 /dev/sdc1 /mnt/.transmission 
real	0m15.146s
user	0m0.000s
sys	0m0.137s

43.177s

O_o

Да, так. Значит, дело не в free space cache.

Zygo: it’d have ~2000 seeks to do at startup, so on a 5900 rpm spinner maybe
Zygo: my 25x larger filesystem has a mount time of just over 6 minutes

Я так понимаю, у тебя ST2000VM003-1CT164? 5900 rpm и есть. Ну значит это норма.

А если вставить третий диск, на нем btrfs и рсинком данные? Может быть так, что у тебя на исходном диске фрагментация чего-то (метаданных, служебных структур). Под торрентами всем фс тяжело приходится.

у тебя ST2000VM003-1CT164?

Да, 5900 rpm.

Ну значит это норма.

Ну, успокоил. А то уж я думал что я бтрфс неправильно готовлю. Значит, про следующий диск (он хоть и крутится быстрее, 7200 рпм, но зато в пять раз больше — 10 TB) и говорить нечего.

Кстати, провёл ещё один эксперимент:

Пытался сконвертировать ext4 в btrfs. btrfs-convert упал. :-( Ладно, хрен с ним, создал btfrs с нуля, заново залил файлы. Сюрприз: mount — всего 2 секунды. Второй сюрприз: umount — 10 секунд!

Ну ладно, mount готовится к использованию, считывает что-то с диска, гоняет головки туда-сюда. Но umount-то что 10 секунд делает?? Между mount и umount ничего не было — к фс никто не обращался, файлов никто не писал, кеш на диск сбрасывать не надо. Но 10 секунд!

# time mount /dev/sde1 /mnt/tmp; time umount /mnt/tmp

real	0m2.252s
user	0m0.002s
sys	0m0.052s

real	0m10.363s
user	0m0.002s
sys	0m0.194s

В то время как на первом диске:

# time mount /dev/sdc1 /mnt/.transmission/; time umount /mnt/.transmission

real	0m15.346s
user	0m0.005s
sys	0m0.135s

real	0m0.311s
user	0m0.001s
sys	0m0.017s

Чудны твои дела, btrfs.

Третий диск у меня совершенно случайно есть, но вставлять его уже некуда — все порты заняты. То, что ты хочешь, со вторым проделал. Результаты, гм, обескураживающие, см. выше.

к фс никто не обращался, файлов никто не писал кеш на диск сбрасывать не надо. Но 10 секунд!

Это вырожденный случай. Обычно-то как раз на диск пишут и алгоритм рассчитан на это. Я не знаю что там происходит, но вполне допускаю что там таймауты на то, чтобы данные из кеша диска дошли до блинов/флеша. И не доверяя носителю в том, что он честно отработает sync (а не отрапортует об успехе ещё ничего не сделав) разработчики btrfs подстраховались с таймаутом.

Я не знаю что там происходит, но вполне допускаю что там таймауты на то, чтобы данные из кеша диска дошли до блинов/флеша.

Допустим, тайм-ауты. Но почему два подобных диска ведут себя по-разному? Почему на одном диске umount завершается за 10 секунд, а на втором — менее чем за одну? Диски одинаковые, условия тоже — mount/umount.

Ладно, я помечаю тему как решённую. Будем считать, что btrfs крутая фс, но я к ней пока не готов.

Давненько игрался с btrfs, первым делом пытался сконвертить из ext4. Оказалось, что в репе конвертер старый. Ну ок поставил самый последний, потом докопался что конвертер не рекомендуется и вообще не поддерживается, мол копируйте данные и всё тут.

Пытался сконвертировать ext4 в btrfs. btrfs-convert упал. :-(

btrfs-convert у меня не падает, но генерит внутренне сломанные ФС, на которых падает ядро. Я бы его не использовал в критичных случаях.

Ладно, хрен с ним, создал btfrs с нуля, заново залил файлы. Сюрприз: mount — всего 2 секунды.

Значит, дело во фрагментации служебных структур btrfs на первом диске. Это известная, я бы даже сказал конструктивная проблема в данной ФС.

Второй сюрприз: umount — 10 секунд!

umount пытался сразу после копирования? Или сколько-то подождал? Учитывая линуксовый writeback кэш и то, как агрессивно он работает при копировании/быстрой записи больших объёмов данных (cf. «12309») — вполне может быть, что это остатки кэша сбрасывались.

umount пытался сразу после копирования?

Если бы. umount сразу после mount:

# time mount /dev/sde1 /mnt/tmp; time umount /mnt/tmp

Хм, это уже не могу воспроизвести, у меня umount быстрый даже на внешнем диске дважды покоцанном.

А долгое монтирование ты воспроизводил?

Нет. Я неправильно выразился. Не могу даже предположить причину и тесткейс для такого поведения.

Ладно, проехали. Теперь, когда ext4 монтируется за доли секунды, её можно и в fstab записать. Осталось 10 TB в ext4 сконвертировать. Жил я до этого без cow, снапшотов и вольюмов, и ещё несколько лет проживу.

Спасибо за помощь. Тема закрыта.