Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

share|improve this question
    
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 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 at 12:49
up vote 13 down vote accepted

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.

share|improve this answer
    
+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
    
@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 Mar 4 '13 at 23:00
    
@Gilles That is a good question and I believe the only reason why find is faster is because of the implementation. Now you got me curious as to the why - I will make time to trace this and find out! – Johan Mar 5 '13 at 7:55

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.

share|improve this answer

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))."

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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