Короткая версия : 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? Это возможно, конечно, но как вы думаете, это может быть актуально? Прямо сейчас я не могу вспомнить, почему я решил попробоватьbtrfs.btrfsпотому что я хотел прозрачное сжатие. Сейчас:rsnapshotиспользует жесткие ссылки. У него нет никакой возможности не использовать жесткие ссылки. Таким образом, жесткие ссылки пересекаются сbtrfsфункцией копирования при записи, но я ничего не могу с этим поделать.Ответы:
Что ж, это все еще проблема Btrfs, хорошо известно, что удаление множества небольших файлов занимает довольно много времени по сравнению с другими файловыми системами.
Если вам это не нравится, вы можете подождать, пока апстрим не исправит это, или перейти к другой файловой системе, которая делает это лучше.
Тем не менее, ваша основная ошибка - использование древнего ядра (3.16, да, оно было уже древним, когда вы писали) с btrfs. Btrfs - это файловая система, которая все еще находится в стадии разработки, поэтому вы всегда должны использовать последнюю и самую лучшую версию ядра, чтобы связаться с улучшениями. Если в вашем дистрибутиве нет бэкпортов, вы можете сделать это самостоятельно, или вы облажались.
Btrfs получил много улучшений производительности в версии ядра 3.19 - это минимальная версия, которую вы должны использовать в производственной среде, ваша версия ядра 3.16 явно отстой без бэкпортов.
Также имейте в виду, что, по словам Криса Мейсона, он до сих пор считает Btrfs стабильным, но еще не готовым к производству.
источник
btrfs. Слишком раскрученный, в то время как его развитие, кажется, берет навсегда.Я немного опоздал на эту вечеринку, но вот уловка, чтобы очень быстро удалить очень большие деревья btrfs:
Ядро начнет восстанавливать пространство в фоновом режиме, поэтому у вас не будет свободного места сразу, но процесс должен быть намного быстрее, чем любое удаление пользовательского пространства.
источник
Вы можете переименовать каталог, а затем удалить переименованный каталог в фоновом режиме. Это не ускорит операцию удаления. Однако это позволило бы программе продолжить работу с пустым каталогом, пока операция удаления происходит на стороне.
Я не уверен, будет ли это работать в вашем случае использования. Это зависит от того, не может ли программа продолжаться до тех пор, пока диск не будет свободен (то есть будет выполнять тяжелые операции с диском). Это зависит от того, собирается ли программа заполнить диск большим количеством данных.
источник