15

I have a folder with 266778 subfolders. How can I delete it?

I have tried

cd ~/.local/share/Trash/
sudo rm -rf *

but it takes much time. After 1 minute 25 seconds real time and 0.072 seconds user time it only deleted 2500 folders. This way, it will take over two hours to delete this folder.

Is there a faster way to delete this folder? Why is there such a big difference between user time and real time?

real    1m25.474s
user    0m0.072s
sys     0m28.142s

I use Linux 2.6.32 (Ubuntu 10.04.4 LTS).

  • I have just googled this problem and it seems that some people have discovered that rsync can be used as a "many-files-deletion" tool quite efficiently. Whether it truly is faster remains up to you to evaluate. – Johan Mar 4 '13 at 12:51
  • 2
    For what it's worth: performance when deleting many folders/files is highly filesystem dependent. In my experience the difference when deleting millions of small files on ext3 (slow) vs. XFS (fast) can be hours. – pdo Apr 18 '16 at 11:11
  • If you often have this case and you can plan ahead, using a filesystem like btrfs and using a subvolume, you can speed things up fast by just dumping that subvolume. – PlasmaHH Apr 18 '16 at 12:49
  • Here is where you can find the answer. The perl one is the fastest. unix.stackexchange.com/questions/37329/… – SDsolar Aug 17 '17 at 10:10
17

If your version of "find" implements the -delete sub-command, then you can try

find directory -delete

In this case:

find ~/.local/share/Trash/ -delete

Some commands, like rm, perform most of their work in the kernel. In the file-system routines, to be exact. Time spent performing system calls are accounted for in that way, so whilst your "rm" command runs for a long time, it doesn't do much work in user-land - the system calls performs most of the work.

  • +1 ; though this also deletes the parent dir and I suspect the OP only wanted to delete the contents of the Trash folder not the folder itself – don_crissti Mar 4 '13 at 14:34
  • 1
    @don_crissti : good remark. if the OP wanted to only delete subdirs under ~/.local/share/Trash (and not files on the 1st level), then : find ~/.local/share/Trash/*/ -delete (of course, this will also delete files (and dirs) in any of those Trash/*/ subdirs as well) – Olivier Dulac Mar 4 '13 at 16:16
  • 2
    +1 for explaining the odd behaviour of time – Martin Thoma Mar 4 '13 at 17:53
  • 3
    Is find directory -delete really faster than rm -rf directory? After all, they perform the same work, and there aren't two ways to do it. – Gilles 'SO- stop being evil' Mar 4 '13 at 23:00
  • 1
    @Johan find is really fast. Did you ever get a chance to find out the reason? – Harshdeep Mar 16 '17 at 16:35
20

It depends on your definition of fast. The answers already here give a good solution for actually removing the directories from the filesystem, but if what you really need is to free the directory name as fast as possible, a rename on the same filesystem is instantaneous:

{ mv directory directory.gone && rm -rf directory.gone; } &

Technically this is cheating since I haven't sped up the actual deletion, but practically it's very useful: I use this trick all the time so I don't have to wait for slow deletion operations.

  • Great. What is your use case for doing this all the time? If you do it a lot, isn't there a danger you will backlog, get multiple 'directory.gone's and fail? I presume you use a suffix like '$$' or '%(date ...)' – smci Nov 28 '17 at 0:37
  • 1
    If I needed that I could probably use mktemp with arguments that ensure it stays on the same filesystem. But I can’t say I have a specific example right now. – kojiro Nov 28 '17 at 0:40
  • kojiro yeah thanks, mktemp is what I was trying to remember... – smci Nov 28 '17 at 1:03
1

rm -rf directory or rm -rf * of course is the fastest method unless your local rm implementation is broken.

Using find gives no advantages.

Whether this is fast or slow mainly depends on the filesystem and OS implementation. So the question seems to be inappropriate.

UFS and ZFS on Solaris are known to be very fast with this kind of task as both filesystem implementations include delayed background delete code that causes the unlink() and rmdir() calls to return fast even when the related object will take more time in total.

With the delayed background delete in the kernel, the directory updates can be done fast as well and this help to speed up the whole operation.

0

This is only a partial answer, sheding light on the three values the command returns; quoted from the time(1) manpage:

(i) the elapsed real time between invocation and termination, (ii) the user CPU time (the sum of the tms_utime and tms_cutime values in a struct tms as returned by times(2)), and (iii) the system CPU time (the sum of the tms_stime and tms_cstime values in a struct tms as returned by times(2))."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.