Huge directory, not files inside, but directory itself

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

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.

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.

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, ...?