Re: generalizing . and ..

Arvind Sankar (arvinds@mit.edu)
Sun, 27 Jun 1999 16:59:05 +0000


On Sun, Jun 27, 1999 at 11:40:36AM -0400, Albert D. Cahalan wrote:
> > But directories *are* just lists of filenames and inode numbers. It's silly
> > to think of it otherwise.
>
> That is an implementation detail. Users are not concerned with that.
>
> > Remember that filename -> inode mapping is many to
> > one (i.e. hard links).
>
> First of all, real users don't do hard links...

This is ridiculous.

>
> > If I have a 1Mb 'file' that is in two directories, should *both*
> > those directories appear to be >1Mb in size? If those two dirs
> > share a parent at some point, should it have a size >2Mb?
>
> Yes and yes. If you were to copy one of the directories somewhere
> else, breaking the hard links, you would get a size calculated
> in an obvious way. This should not be different; files do not
> grow when you move them.
>
> If I have a 4 MB file and I hard link it, I do not then see two
> links that claim to represent 2 MB of data each. No, they both
> show the whole 4 MB.

Each inode would need to store a list of directories in which it is linked.
Hard linking would no longer be efficient. Nothing would be efficient, in fact.
I seriously doubt that it is worth taking that hit for some abstract notion of
what a directory's size should be.

And even that abstract notion is questionable. Why should directories be thought
of as holding everything beneath them recursively? It makes equal if not better
sense that they hold exactly what you get when you readdir() them. In which case
the size should be one of
1) size allocated, as is current scheme
2) actual number of bytes used by directory entries
3) number of directory entries
4) total size of all the files corressponding to the directory entries

There are reasons that 1) is preferred, basically that a directory is stored
(at least in ext2) as a file with possible unused space in it. Another
filesystem with a different storage layout for directories is free to choose a
different interpretation.

-- arvind

-
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/