Укороченная версия: rm -rf mydir, с участием mydir (рекурсивно), содержащий 2,5 миллиона файлов, занимает около 12 часов на почти неработающей машине.
Больше информации: Большинство удаляемых файлов представляют собой жесткие ссылки на файлы в других каталогах (удаляемый каталог фактически является самой старой резервной копией, сделанной rsnapshot; в rm команда фактически дается rsnapshot). Таким образом, в основном удаляются записи каталога - самого содержимого файла не так много; это порядка нескольких десятков ГБ.
Я далеко не уверен, что btrfs виноват. Я помню, что резервное копирование было очень медленным, прежде чем я начал использовать btrfs, но я не уверен, что удаление было медленным.
Это процессор Intel Core i5 2,67 ГГц с 4 ГБ оперативной памяти. У него два диска SATA: на одном установлена ОС и еще кое-что, а резервный диск - 1 ТБ. WDC WD1002FAEX-00Z3A0. Материнская плата - Asus P7P55D.
редактировать: Машина - хриплый Debian с Linux 3.16.3-2~bpo70+1. Вот как монтируется файловая система:
root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)
редактировать: С помощью rsync -a --delete /some/empty/dir mydir занимает около 6 часов. Значительное улучшение по сравнению с rm -rf, но все же слишком много думаю. (Объяснение почему rsync быстрее чем rm: "[M] Остальные файловые системы хранят свои структуры каталогов в формате btree, порядок [в], в котором вы удаляете файлы ... важен. Необходимо избегать перебалансировки btree при выполнении отмены связи .... rsync -a --delete ... делает удаления по порядку ")
редактировать: Я прикрепил другой диск, на котором было 2,2 миллиона файлов (рекурсивно) в каталоге, но на XFS. Вот некоторые сравнительные результаты:
On the XFS disk On the BTRFS disk
Cached reads[1] 10 GB/s 10 GB/s
Buffered reads[1] 80 MB/s 115 MB/s
Walk tree[2] 11 minutes 43 minutes
rm -rf mydir[3] 7 minutes 12 hours
[1] С hdparm -T /dev/sdX и hdparm -t /dev/sdX.
[2] Время, необходимое для запуска find mydir -print|wc -l сразу после загрузки.
[3] На диске XFS это было вскоре после обхода дерева с find. На диске BTRFS это старое измерение (и я не думаю, что это было с кешированным деревом).
Похоже, проблема с btrfs.
Что ж, это все еще проблема Btrfs, это хорошо известно, что удаление многих небольших файлов занимает довольно много времени по сравнению с другими файловыми системами.
Если вам это не нравится, вы можете либо дождаться, пока апстрим исправит это, либо перейти к другой файловой системе, которая делает это лучше.
Однако ваша основная ошибка заключается в использовании древнего ядра (3.16, да, оно уже было древним, когда вы писали) с btrfs. Btrfs - это файловая система, которая все еще находится в стадии интенсивной разработки, поэтому вы всегда должны использовать самую последнюю и лучшую версию ядра, чтобы иметь возможность ознакомиться с улучшениями. Если в вашем дистрибутиве нет бэкпортов, вы можете сделать это сами, или вы облажались.
Btrfs получил много улучшений производительности в версии ядра 3.19 - это минимальная версия, которую вы должны использовать в производстве, ваше ядро версии 3.16 явно отстой без обратных портов.
Также имейте в виду, что, по словам Криса Мэйсона, он действительно считает Btrfs стабильным, но еще не готовым к производству.
Я немного опоздал на эту вечеринку, но вот трюк, позволяющий очень быстро удалить очень большие деревья btrfs:
Ядро начнет восстанавливать пространство в фоновом режиме, поэтому у вас не сразу появится доступное пространство, но процесс должен быть намного быстрее, чем любое удаление на уровне пользователя.
Вы можете переименовать каталог, а затем удалить переименованный каталог в фоновом режиме. Это не ускорит операцию удаления. Однако это позволит программе продолжить работу с пустым каталогом, пока операция удаления выполняется на стороне.
Я не уверен, что это сработает в вашем случае использования. Это зависит от того, не может ли программа продолжаться до тех пор, пока диск не простаивает (т.е. он собирается выполнять некоторые тяжелые операции с диском). Это зависит от того, собирается ли программа заполнять диск большим количеством данных.