LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


0

1

В продолжение этой темы.

Есть два одинаковых диска, различаются только серийным номером. Куплены в одно время, наработка примерно одинаковая. Объём 2 TB. Интерфейс дисков SATA 3.0 6.0 Gb/s, но подключены к портам 3.0 Gb/s на маме. smart у обоих похож; на мой взгляд, ничего криминального. Разметка (почти) одинаковая: GPT, по одному разделу на весь диск (начиная с сектора 2048, конец слегка разный: 3907028991 vs 3907029134 — я уже не помню, почему). Содержимое дисков одинаковое: 53290 файлов и каталогов, общим объёмом под 2 TB (на самом деле на втором диске на один файл/каталог больше: там есть lost+found). Все файлы скопированы с первого диска на второй при помощи rsync -aX. На первом диске btrfs, на втором — ext4. На первом диске свободно 62 GB (мелочь, а приятно), на втором — 0 (это понятно: Reserved block count: 24418919). Главное: первый диск монтируется 15 секунд, второй — моментально:

# time mount /dev/sdc1 /mnt/tmp
real    0m15.009s
user    0m0.002s
sys	    0m0.134s

# time mount /dev/sde1 /mnt/tmp
real    0m0.132s
user    0m0.002s
sys     0m0.026s

Размонтирование тоже различается: первый — около 5 секунд, второй — моментально.

Не то чтоб для меня это было критично, но просто любопытно: Это нормально?

Кстати, перед тем, как создать на втором диске ext4, я на нём же делал brtfs. Новенькая и пустая btrfs монтируется моментально.

★★★★★

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

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

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

Так?

# 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
debugger ★★★★★
() автор топика

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 и есть. Ну значит это норма.

intelfx ★★★★★
()

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

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

у тебя ST2000VM003-1CT164?

Да, 5900 rpm.

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

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

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

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

Пытался сконвертировать 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# time mount /dev/sde1 /mnt/tmp; time umount /mnt/tmp
debugger ★★★★★
() автор топика
Ответ на: комментарий от intelfx

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

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

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