I'm a newbie to ext3 file system, but what a pity if
ext3 could not shrink after containing files and
subdirectories get deleted.
If the ext3 directory could not shrink, then another
natural question is: can the deleted directory entries
be overwritten by new files/subdirs? The following is
an example to detail my question:
Suppose a directory named myDir hold 3 files a, b, c.
then the ext3 file system will create 5 entries under
myDir, ".", "..", 'a', 'b', 'c'.
lets say I remove file a and b, then the entries on
et3 will looks as:
'.', '..', '#a', '#b', 'c'. with '#?' means the file
at last I added three files d ,e,f, which entries
should the ext3 file system create for myDir? case A,
or case B? it looks like case A has better performance
and is not hard to implement. But I'm not sure how
case A, '#a', '#b' entries are reused, so only one
more entries are created.
'.', '..', 'd', 'e', 'c', 'f'.
case B, '#a', '#b' are not reused, instead, 3 more
entries are created. so total entries are:
'.', '..', '#a', '#b', 'c', 'd', 'e', 'f'.
Please help, I'll be more than appreciated if any one
can point out ext3 howtos and introduction links.
Thanks a lot.
--- John Wendel <jwendel10 comcast net> wrote:
Robinson Tiemuqinke wrote:
> 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
> 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
> so I try to 'ls' the directory itself (not any
> subdirectories on it) and find that its size is
stupidly large (it is
> 131M even after deletion) compared with 4K for
> -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
> machine? I'm afraid of the commands "rsync -avHn
/tmp/ /new_tmp/; rm
> -rf /tmp/ && mv /new_tmp/ /tmp" because other
> accessing /tmp/ as well.
> Please help. Thanks a lot.
EXT3 directories grow but they don't shrink.
Rebooting won't fix this
The only fix that I know is to delete the old
directory and create a new
BTW, XFS automatically shrinks directories (but has
its own set of