Я пытался использовать 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
источник
fuseblkозначает, что диск не является NTFS, это означает, что он монтируется как блочное устройство FUSE. Это может быть что угодно.Ответы:
В конечном счете, независимо от того, что вы делаете,
rmнужно запускатьunlinkкаждый файл, который вы хотите удалить (даже если вы вызываетеrm -rродительский каталог). Если нужно удалить много файлов, это может занять много времени.При запуске есть два особенно трудоемких процесса
rm -r:readdir, с последующим,unlink.Поиск всех файлов, а затем просмотр каждого файла для его удаления может занять очень много времени.
Если вы обнаружите, что это «непригодно для использования», потому что оно делает каталог непригодным на некоторое время, рассмотрите возможность перемещения родительского каталога перед его удалением. Это освободит это имя для повторного использования программы, без особых неудобств.
Предполагая, что файловая система действительно является NTFS (это неясно из вашего вопроса), NTFS обычно довольно медленно удаляет большие массивы файлов. Вы можете рассмотреть возможность использования более подходящей файловой системы для ваших целей (более поздние файловые системы ext имеют довольно хорошую производительность удаления, если у вас нет каких-либо особых потребностей). Сам FUSE тоже не особо быстрый, в общем. Вы можете посмотреть, можете ли вы сделать это каким-либо образом, который не использует FUSE.
источник
Почему рм так медленно? Не имею представления. Но я знаю более быстрый путь:
Обновление: у этого ответа на Serverfault есть некоторые объяснения. Похоже, что rsync удаляет файлы в определенном порядке, что приводит к тому, что дерево файловой системы остается сбалансированным и не нуждается в повторной балансировке. rm просто удалит файлы и приведет к значительной перебалансировке при их удалении. Существует некоторая информация о перебалансирования здесь .
источник
rm -rf?rsyncвсе еще нужноunlink()все файлы вtest/, и это, вероятно, то, что занимает время.unlink(2)в каталоге (и помнить, чтобы сделатьfsckпозже) ...Ну, у меня когда-то была похожая проблема с твоей. Я обнаружил, что ваш "ва" высок, вы могли бы использовать
чтобы проверить, высока ли ваша утилита диска, если это так, это означает, что ваш диск достаточно занят. Убедитесь, что некоторые другие процессы постоянно записывают на диск.
Для простоты используйте
чтобы проверить, является ли b высоким или r < b . Это указывает на что-то не так. В вашей ситуации, я думаю, диск io является оригинальной причиной.
источник