Удаление файлов занимает слишком много времени

Короткая версия : 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 Wheezy с 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, порядок [in], в котором вы удаляете файлы, ... важен. Необходимо избегать перебалансировки 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:

1. Создайте фиктивный подобъем в той же файловой системе btrfs.
2. Переместите каталог верхнего уровня, который вы хотите удалить, в упомянутый подобъем - эта операция должна быть очень быстрой, если вы выполняете ее в одной и той же файловой системе btrfs, даже между подобъемами.
3. Уничтожить вложенный том.

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

Вы можете переименовать каталог, а затем удалить переименованный каталог в фоновом режиме. Это не ускорит операцию удаления. Однако это позволило бы программе продолжить работу с пустым каталогом, пока операция удаления происходит на стороне.

Я не уверен, будет ли это работать в вашем случае использования. Это зависит от того, не может ли программа продолжаться до тех пор, пока диск не будет свободен (то есть будет выполнять тяжелые операции с диском). Это зависит от того, собирается ли программа заполнить диск большим количеством данных.