[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <bob@proulx.com> wrote:
Bilal mk wrote:
> I tried to remove 5GB directory. In that directory around 30000 files and
> directory. It will take more than 30 min to complete.

A large number of files consuming a large number of blocks will take a
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..

> There is no other cpu intensive process running. After sometime it goes to
> D state and unbale to kii that process.

If you have processes stuck in the D state (uninterruptible sleep)
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.

Thanks



> I have also tried find with xargs method to remove. It will also take long
> time to complete
> find /directory | xargs rm -rf

I doubt the problem is in rm since it has already been optimized to be
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.

Bob


Reply to: