Messages in this thread | | | Date | Fri, 25 Jun 1999 02:55:13 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: why is the size of a directory always 1024b ? |
| |
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/
| |