Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have been trying to delete a directory from a centos server using rm -Rf /root/FFDC for the past 15 hours and am having great difficulty. I can't do a directory listing because it hangs the system (too many files?) but what I can see is that the directory size is not the usual 4096 bytes but 488MB!

[root@IS-11034 ~]# ls -al
total 11760008
drwxr-x--- 31 root root        4096 Aug 10 18:28 .
drwxr-xr-x 25 root root        4096 Aug 10 16:50 ..
drwxr-xr-x  2 root root   488701952 Aug 11 12:20 FFDC

I've checked the inodes and everything seems fine. I've checked top and rm is still using the cpu after 15 hours at 0.7%. Filesystem type is ext3.

I'm clueless where to go now apart from backup and format.

share|improve this question
    
What happens if you stat that directory? –  Andrew Aug 11 '10 at 16:12
add comment

4 Answers

up vote 1 down vote accepted

Is even ls -1f /root/FFDC slow? With -1f the output won't be sorted and the file details will be left out.

If the ls above runs fast, perhaps something like find /root/FFDC | xargs rm -vf would be faster? A normal rm -rf might do all kind of recursion which the findMIGHT be able to skip. Or then not.

Is your filesystem mounted with sync option? If it is, then the write/delete performance is horribly slower than it could be with async. If in doubt, you might try mount -o remount,async / (or mount -o remount,async /root if that's a separate filesystem for you).

share|improve this answer
add comment

Have you considered unmounting the filesystem and then running e2fsck to check the file system for errors? I would try this before backup, format, restore.

share|improve this answer
add comment

running fsck on the filesystem will fix the problem. It usually occurs when a directory used to contain many files but now no longer does. The directory size is given as a huge number and the performance suffers.

share|improve this answer
add comment

I'm not sure fsck(8) will reorganize directories, you might try the -D flag (as described in e2fsck(8)). If it doesn't, and if there really aren't millions of files in that directory, perhaps something like the following gives a reasonably-sized directory:

cd /root mv FFDC FFCD-old mkdir FFCD # Adjust permissions on FFDC mv FFDC-old/* FFDC # Check/move any .xxx files/directories in FFDC-old rmdir FFCD-old

At least several bash versions get globs like .a[^.]* wrong and include . and .. anyway, else you might try the next to last step as mv FFDC-old/.* FFDC

Filesystems like ext3/ext4 handle directories essentially as linked lists of unmovable nodes with space for filename + inode number, when a file is unlinked the space for the name is freed (and should coalesce with free neighbor entries, if any). So such a gigantic directory with few files can be created, but it isn't easy. Perhaps creating millions of hard links to the same few files? Creating/deleting millions of links with carefully crafted names? Whatever happened to create this merits investigating; is it a prank, a filessystem malfunction of some sort, ...?

share|improve this answer
add comment

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.