I have a directory of 30 TB having billions of files in it which are formally all JPEG files. I am deleting each folder of files like this:

sudo rm -rf bolands-mills-mhcptz

This command just runs and doesn't show anything whether it's working or not.

I want to see as it's deleting files or what is the current status of the command.

  • 21
    Not answers: Sometimes it is faster to backup the stuff you want to keep, format, and restore the stuff you want to keep. Other answers: unix.stackexchange.com/questions/37329/… Commented Dec 1, 2016 at 17:59
  • 2
    If you just want an idea of progress, rather than knowing which particular files have been removed, you could run "df /dev/sd_whatever_the_drive_is".
    – jamesqf
    Commented Dec 1, 2016 at 18:21
  • 13
    How did you end up with billions of files in a single directory?? Commented Dec 2, 2016 at 16:44
  • 1
    @MichaelHampton But if the files aren't a separate dataset, it may take a long time. (on ZFS) serverfault.com/questions/801074/…
    – v7d8dpo4
    Commented Dec 3, 2016 at 15:28
  • 5
    Billions of files, huh? Try rm -ri. It will be fun!
    – AAM111
    Commented Dec 4, 2016 at 21:52

6 Answers 6


You can use rm -v to have rm print one line per file deleted. This way you can see that rm is indeed working to delete files. But if you have billions of files then all you will see is that rm is still working. You will have no idea how many files are already deleted and how many are left.

The tool pv can help you with a progress estimation.


Here is how you would invoke rm with pv with example output

$ rm -rv dirname | pv -l -s 1000 > logfile
562  0:00:07 [79,8 /s] [====================>                 ] 56% ETA 0:00:05

In this contrived example I told pv that there are 1000 files. The output from pv shows that 562 are already deleted, elapsed time is 7 seconds, and the estimation to complete is in 5 seconds.

Some explanation:

  • pv -l makes pv to count by newlines instead of bytes
  • pv -s number tells pv what the total is so that it can give you an estimation.
  • The redirect to logfile at the end is for clean output. Otherwise the status line from pv gets mixed up with the output from rm -v. Bonus: you will have a logfile of what was deleted. But beware the file will get huge. You can also redirect to /dev/null if you don't need a log.

To get the number of files you can use this command:

$ find dirname | wc -l

This also can take a long time if there are billions of files. You can use pv here as well to see how much it has counted

$ find dirname | pv -l | wc -l
278k 0:00:04 [56,8k/s] [     <=>                                              ]

Here it says that it took 4 seconds to count 278k files. The exact count at the end (278044) is the output from wc -l.

If you don't want to wait for the counting then you can either guess the number of files or use pv without estimation:

$ rm -rv dirname | pv -l > logfile

Like this you will have no estimation to finish but at least you will see how many files are already deleted. Redirect to /dev/null if you don't need the logfile.


  • do you really need sudo?
  • usually rm -r is enough to delete recursively. no need for rm -f.
  • 6
    Nice use of pv, assuming it's not too expensive to count the billions of files ;-). (It might take nearly as much time as the rm it's supposed to measure!) Commented Dec 1, 2016 at 14:36
  • 7
    @StephenKitt This is what really annoys me (and many other people) about the Windows file utility: it always, without fail, counts the number and sizes of files before deleting which, unless the drive is much slower than the processor, takes almost as long as the actual deletion!
    – wizzwizz4
    Commented Dec 1, 2016 at 17:37
  • 7
    @StephenKitt Maybe I'm mistaken, but isn't the bottleneck, besides the disk access, the terminal output? I believe pv refreshes the progress bar only once per second, despite its input. So, the terminal only needs to display one line instead of a ton each second. pv only needs to increment a counter for each newline it encounters; that's got to be faster than doing line wrapping, and whatnot for displaying a line in a terminal. I think running with pv like this is causes the file removals to be faster than simply rm -rv.
    – JoL
    Commented Dec 1, 2016 at 19:25
  • 1
    @jlmg you're right, the output will take time. My comment stemmed from the fact that the OP's silent rm is taking a very long time already, so simply counting the files is also going to take a very long time. (Since the OP's current command is silent, terminal output isn't a bottleneck in the question.) Commented Dec 1, 2016 at 19:39
  • 2
    @skywinder rm -rv dirname | pv -l -s $(find dirname | wc -l) > logfile
    – Lesmana
    Commented Aug 12, 2017 at 14:23

Check out lesmana's answer, it's much better than mine — especially the last pv example, which won't take much longer than the original silent rm if you specify /dev/null instead of logfile.

Assuming your rm supports the option (it probably does since you're running Linux), you can run it in verbose mode with -v:

sudo rm -rfv bolands-mills-mhcptz

As has been pointed out by a number of commenters, this could be very slow because of the amount of output being generated and displayed by the terminal. You could instead redirect the output to a file:

sudo rm -rfv bolands-mills-mhcptz > rm-trace.txt

and watch the size of rm-trace.txt.

  • 5
    This can actually slow the delete down because of all the output being generated and rendered to a terminal :) Commented Dec 2, 2016 at 14:10
  • 2
    Of course it will slow down. Writing billions of lines to a file does not happen in zero time.
    – user207421
    Commented Dec 3, 2016 at 23:16

Another option is to watch the number of files on the filesystem decrease. In another terminal, run:

watch  df -ih   pathname

The used-inodes count will decrease as rm makes progress. (Unless the files mostly had multiple links, e.g. if the tree was created with cp -al). This tracks deletion progress in terms of number-of-files (and directories). df without -i will track in terms of space used.

You could also run iostat -x 4 to see I/O operations per second (as well as kiB/s, but that's not very relevant for pure metadata I/O).

If you get curious about what files rm is currently working on, you can attach an strace to it and watch as the unlink() (and getdents) system calls spew on your terminal. e.g. sudo strace -p $(pidof rm). You can ^c the strace to detach from rm without interrupting it.

I forget if rm -r changes directory into the tree it's deleting; if so you could look at /proc/<PID>/cwd. Its /proc/<PID>/fd might often have a directory fd open, so you could look at that to see what your rm process is currently looking at.

  • 2
    df -ih is indeed a nice cheap way of watching rm progress. Commented Dec 2, 2016 at 8:01
  • BTW, this doesn't work on BTRFS, where the used-inode count is always zero. :( Same for FAT32, but you probably don't have billions of files on your /boot EFI system partition. Commented Dec 30, 2016 at 2:09
  • if you don't have watch, this seems to do ok -- for (( ; ; )); do; clear; df -ih /path/to/dir; sleep 5; done Commented Feb 12, 2023 at 2:19

While the above answers all use rm, rm can actually be quite slow at deleting a large numbers of files, as I recently observed when extracting ~100K files from a .tar archive actually took less time than deleting them. Although this does not actually answer the question you asked, a better solution to your problem might be to use a different method to delete your files, such as one of the upvoted answers to this question.

My personal favorite method is to use rsync -a --delete. I find that this method performs fast enough that it's worth the ease-of-use over the most upvoted answer to that question, in which the author has written a C program that you would need to compile. (Note that this will output every file being processed to stdout, much like rm -rv; this can slow down the process by a surprising amount. If you do not want this output, use rsync -aq --delete or redirect the output to a file instead.)

The author of that answer says:

The program will now (on my system) delete 1000000 files in 43 seconds. The closest program to this was rsync -a --delete which took 60 seconds (which also does deletions in-order, too but does not perform an efficient directory lookup).

I have found that this is good enough for my purposes. Also potentially important from that answer, at least if you're using ext4:

As a forethought, one should remove the affected directory and remake it after. Directories only ever increase in size and can remain poorly performing even with a few files inside due to the size of the directory.

  • huh, I would have expected rm and/or find --delete to be efficient. Interesting point about deleting in sort order to avoid b-tree rebalances while deleting. Not sure how much of that applies to other filesystems. XFS is also not great with millions of files per directory. IDK about BTRFS, but I'm under the impression that it might be good for that sort of thing. Commented Dec 3, 2016 at 19:18
  • Doesn't that second quote depend on the type of filesystem...
    – Menasheh
    Commented Dec 4, 2016 at 5:14
  • @Menasheh Good point, I edited that into my answer. Commented Dec 5, 2016 at 7:15

One thing you could do would be to start up the rm process in the background (with no output, so it won't be slowed down) and then, monitor it in the foreground with a simple(a) command:

pax> ( D=/path/to/dir ; rm -rf $D & while true ; do
...>   if [[ -d $D ]] ; then
...>     echo "$(find $D | wc -l) items left"
...>   else
...>     echo "No items left"
...>     break
...>   fi
...>   sleep 5
...> done )

27912 items left
224 items left
No items left

pax> _

The find/wc combo could be replaced with any tool able to give you the units you want.

(a) Well, relatively simple, compared to, say, nuclear physics, the Riemann hypothesis, or what to buy my wife for Xmas :-)


A while ago I wrote something to print the rate that lines were printed. You can run rm -rfv | ./counter and it will print lines per sec/min. Although not a direct progress, it will give you some feedback on the progress rate, maybe the rm wandered into a network filesystem or similar perhaps?

Link to the code is here:


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .