Почему скорость записи на внешнем накопителе (подключенном через USB, тип fuseblk) с 50 ГБ файлов медленнее?

21

Я пытался использовать rsnapshot для создания резервных копий, но я нахожу его непригодным для использования. Несмотря на то, что он может различать каталог (50 ГБ) и дублировать его (жестко связывая каждый файл) за несколько минут, а я могу просмотреть весь каталог примерно за полчаса, его удаление займет более часа. rm -rfvЯ обнаружил, что даже непосредственное использование может занять до полсекунды для получения одного файла, тогда как команды cpи linkвыполняются мгновенно.

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

Файловая система, над которой я работаю, - это внешний накопитель, подключенный через usb и тип fuseblk (что, я думаю, означает, что это ntfs). Мой компьютер работает под управлением Ubuntu Linux.

Выход сверху:

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers

performance rm external-hdd

— Benubird
источник

1

Монтирование как fuseblkозначает, что диск не является NTFS, это означает, что он монтируется как блочное устройство FUSE. Это может быть что угодно.

— Крис Даун

1

@ChrisDown Да, но я знаю, что это либо NTFS, либо ext3, и я уверен, что если бы это был ext3, он был бы монтирован как таковой без монтирования аргументов.

— Benubird

1

Это зависит от того, сколько файлов находится в каталоге (вы не сказали, сколько), и, в частности, NTFS замедляется, имея в каталоге только> 3K файлов. Практически любая другая файловая система намного более производительна. Посмотрите все другие посты на SO / SE о влиянии количества файлов на производительность файловой системы.

— Смчи

28

В конечном счете, независимо от того, что вы делаете, rmнужно запускать unlinkкаждый файл, который вы хотите удалить (даже если вы вызываете rm -rродительский каталог). Если нужно удалить много файлов, это может занять много времени.

При запуске есть два особенно трудоемких процесса rm -r:

readdir, с последующим,
количество звонков на unlink.

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

Если вы обнаружите, что это «непригодно для использования», потому что оно делает каталог непригодным на некоторое время, рассмотрите возможность перемещения родительского каталога перед его удалением. Это освободит это имя для повторного использования программы, без особых неудобств.

Предполагая, что файловая система действительно является NTFS (это неясно из вашего вопроса), NTFS обычно довольно медленно удаляет большие массивы файлов. Вы можете рассмотреть возможность использования более подходящей файловой системы для ваших целей (более поздние файловые системы ext имеют довольно хорошую производительность удаления, если у вас нет каких-либо особых потребностей). Сам FUSE тоже не особо быстрый, в общем. Вы можете посмотреть, можете ли вы сделать это каким-либо образом, который не использует FUSE.

— Крис Даун
источник

2

+1 На самом деле многое зависит от конкретной файловой системы - многие, как правило, работают очень хорошо для одних операций, в то время как медлительны с другими (часто это для создания файлов против удаления или доступа к данным).

— Петер

15

Почему рм так медленно? Не имею представления. Но я знаю более быстрый путь:

mkdir blank
rsync -a --delete blank/ test/

Обновление: у этого ответа на Serverfault есть некоторые объяснения. Похоже, что rsync удаляет файлы в определенном порядке, что приводит к тому, что дерево файловой системы остается сбалансированным и не нуждается в повторной балансировке. rm просто удалит файлы и приведет к значительной перебалансировке при их удалении. Существует некоторая информация о перебалансирования здесь .

— rjmunro
источник

1

Вы сравнивали это и сравнивали rm -rf? rsyncвсе еще нужно unlink()все файлы в test/, и это, вероятно, то, что занимает время.

— MattBianco

Я не тестировал это формально, но попробовал, прочитав чужие тесты, и разница была существенной. Я больше не могу найти этот пост, но у этого ответа на serverfault есть объяснение и источник для еще более быстрой программы удаления.

— rjmunro

Но самый быстрый метод должен быть unlink(2)в каталоге (и помнить, чтобы сделать fsckпозже) ...

— MattBianco

Факт есть факт. Просто рассчитал время, и это почти вдвое быстрее. После прочтения GNU-кода coreutils rm это даже не заставляет меня удивляться ...

— Доминик Джордж

1

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

iostat -x 1

чтобы проверить, высока ли ваша утилита диска, если это так, это означает, что ваш диск достаточно занят. Убедитесь, что некоторые другие процессы постоянно записывают на диск.

Для простоты используйте

vmstat 1

чтобы проверить, является ли b высоким или r < b . Это указывает на что-то не так. В вашей ситуации, я думаю, диск io является оригинальной причиной.

— Фибоначи
источник