extremely slow "ls" on a cleared fatty ext3 directory on FC4/5

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



 A stupid flat directory /tmp holding 5 millon files,
the directory locates on a ext3 file system with
dir_index feature turned on. The running Linux are FC4
and FC5.
 The files are just directly under /tmp, not in any
subdirectories -- they are results of mis-operations
of users.

 Then a 'ls' or 'find' command will take one hour to
finish, a lot of other applications on the computer
boxes are affected. 

I managed to have deleted the files one by one with a
'find . |xargs rm -rf' similar command in about 10
hours. but after a file system sync, it still take me
20 minutes to list the cleaned /tmp directory again --
even now the directory holds only 8 files total.

so I try to 'ls' the directory itself (not any files
and subdirectories on it) and find that its size is
stupidly large (it is 131M even after deletion)
compared with 4K for normal directories.

-bash-3.00# ls -alFdh /tmp*
drwxrwxrwt  4 root  staff 4.0K Aug 12 23:17 new_tmp/
drwxrwxrwt  4 root  staff 131M Aug 12 20:30 tmp/

Anyone know why the former fatty directory still looks
unchanged and takes hours to traverse even after
99.999999% files got removed? 

If there are any ways to fix this kind of problem
without rebooting machine? I'm afraid of the commands
"rsync -avHn /tmp/ /new_tmp/; rm -rf /tmp/ && mv
/new_tmp/ /tmp" because other applications are
accessing /tmp/ as well.

Please help. Thanks a lot.

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux