Re: why is the size of a directory always 1024b ?

Alexander Viro (viro@math.psu.edu)
Fri, 25 Jun 1999 02:55:13 -0400 (EDT)


On Fri, 25 Jun 1999, MURALI N wrote:

>
> :Present scheme doesn't create lost+found. It is done by mkfs which has
> :perfectly valid reason to make it larger than 1 block.
>
> Alright. Obviously I have chosen a bad example. Here is another one.
> All said, my point still remains. I still think that we have to change the
> way directories are handled.
>
> "/home/....../abc"
>
> total 5
> drwxrwxr-x 2 muralin muralin 4096 Jun 25 10:14 .
> drwxr-xr-x 13 muralin muralin 1024 Jun 25 10:09 ..

And? Is it a mountpoint with different block sizes on mounted and
underlying filesystems? Or you had a bunch of files there at some moment?
Directories do not shrink. Any sort of shuffling the stuff towards the
beginning and truncating the tail *begs* for trouble. Syscall should not
touch too many metadata blocks - the more you are touching the bigger odds
to screw up on a dirty reboot you get. There is a very good reason why
entries do not cross the block boundary - we don't have to worry about
ordering of writes that way (well, we have, but not as hard as in case
of VFAT which *has* such entires).
Trimming the slack on the fly is royal PITA. Doing it upon request
is trivial - cp -rl foo foo.old; rm -rf foo; mv foo.old foo; (or doing the
same by hands).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/