Hi, all, 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 is delteded. 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 ext3 picks. 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@xxxxxxxxxxx> wrote: > Robinson Tiemuqinke wrote: > > Hi, > > > > 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. > > EXT3 directories grow but they don't shrink. > Rebooting won't fix this > problem. > The only fix that I know is to delete the old > directory and create a new > one. > BTW, XFS automatically shrinks directories (but has > its own set of > problems). > > Regards, > > John > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
