Re: rm -rf is too slow on large files and directory structure(Around 30000)
On Wed, Feb 15, 2012 at 12:14 PM, Bob Proulx <firstname.lastname@example.org>
Bilal mk wrote:A large number of files consuming a large number of blocks will take a
> I tried to remove 5GB directory. In that directory around 30000 files and
> directory. It will take more than 30 min to complete.
significant amount of time to process. That is all there is to it.
Some filesystems are faster than others. What filesystem are you
using? On what type of cpu?
If you happen to be destroying an entire filesystem then you could
simply destroy the entire filesystem by unmounting it and then making
a new filesystem on top of it..
If you have processes stuck in the D state (uninterruptible sleep)
> There is no other cpu intensive process running. After sometime it goes to
> D state and unbale to kii that process.
then something bad has happened. This would indicate a bug.
It sounds like you are having kernel bugs. You may need to fsck your
filesystems. I would double check that dma is enabled to your drives.
I am using xfs filesystem and also did the fsck. DMA is enabled.
Also perfomed xfs defragmentation( xfs_fsr). But still an issue not only rm -rf but also cp command
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1134 0.0 0.0 0 0 ? D 10:18 0:00 [kdmflush]
I have also tested disk with smartmontools. But reported no issues.
My kernel version is 2.6.32-5-amd64. I have also used same configuartion(same kernel) and same hardware on another machine. But on that machine there is no issue.
Is it a kernel bug or hardware issue. Any suggestion for troubleshooting or fix this issue.
I doubt the problem is in rm since it has already been optimized to be
> I have also tried find with xargs method to remove. It will also take long
> time to complete
> find /directory | xargs rm -rf
quite fast. The newer versions have even more optimization. But it
isn't worth the trouble to do anything other than wait. Most of the
time will be spent in the kernel organizing the now free blocks.
If you want to experiment you could try find.
find /directory -depth -delete
That is basically the same as rm -rf but using find only.