Короткая версия: rm -rf mydir
, с mydir
(рекурсивно) содержа 2,5 миллиона файлов, занимает приблизительно 12 часов на главным образом неактивной машине.
Больше информации: большинство удаляемых файлов является жесткими ссылками на файлы в других каталогах (удаляемый каталог является на самом деле самым старым резервным копированием, сделанным rsnapshot
; rm
командой на самом деле дают rsnapshot
). Таким образом, это - удаляемые главным образом записи каталога - само содержание файла не очень; это находится в порядке некоторых десятков ГБ.
Я совсем не уверен это btrfs
преступник. Я вспоминаю, что резервное копирование было также очень медленным, прежде чем я начал использовать btrfs
, но я не уверен, что замедление было в удалении.
Машиной является Intel Core i5 2.67 GHz с 4 ГБ RAM. Это имеет два диска 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]ost, файловые системы хранят свои структуры каталогов в формате B-дерева, порядок [в] котором Вы удаляете файлы... важен. Нужно постараться не восстанавливать равновесие B-дерева, когда Вы выполняете удаление связь.... 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 просто отстой без Backports.
Также имейте в виду, что, по словам Криса Мэйсона, он действительно считает Btrfs стабильным, но еще не готовым к производству.
Я немного опоздал на эту вечеринку, но вот уловка, позволяющая очень быстро удалить очень большие деревья btrfs:
Ядро будет запущено освобождение места в фоновом режиме, поэтому у вас не сразу появится доступное пространство, но этот процесс должен быть намного быстрее, чем любое удаление на уровне пользователя.