> Steve Dodd writes:
> > On Sun, Jun 27, 1999 at 04:09:44AM -0400, Rick Hohensee wrote:
>
> >> Intuition tells you that /usr is not 1k. Or it did before you became
> >> immersed in unix. The "size of a directory" is not the size of the
> >> "file" containing the names of the files and subdirs in a directory.
> >> It's the du of the directory. That's the size. The greenest newbie
> >> makes more sense in this regard than the "illuminati" often do.
>
> Yes, the newbie is obviously correct. The size of a directory ought
> to be the sum of the sizes of all files below it plus overhead.
> I suppose that includes indirect blocks, inodes, ACL data...
>
> Note that the above would allow directory quotas. DG-UX has that.
> Directory quotas kill some of the reasons to have many partitions.
>
> If you want blocks, use the st_blocks member of struct stat.
> It is redundant to make st_size be simply st_blocks*1024.
>
> Unfortunately, the obvious "du" method requires updating all parent
> directories when something changes. Hmmm, they should be in RAM.
> The next best choice is "number of files", used to assist software.
>
> > 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...
>
> > 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.
>
> > It gets worse for the 'inherited mtime' stuff, AFAICS. If I modify
> > a file that appears in two directories, should both their mtimes
> > be changed? How does the kernel know which directories need to be
> > altered? The dentry will only allow us to change the mtime on the
> > directory that we happened to use to lookup the file when we opened
> > it, which is obviously nonsense.
>
> You can only inherit an mtime from one place, so you obviously would
> update that one place. (inheritance means there is _one_ mtime on disk)
>
> You have to ask for mtime inheritance anyway. With that being outside
> of POSIX already, it is OK to ban hard links when mtime is shared.
>
> > And besides, doing that throws away information that might be useful,
> > i.e. when the directory itself was really changed (filename creat / unlink).
>
> The directory and files are tightly related. Inheritance means that
> they actually share some inode data on disk. Reiserfs does not use
> traditional inodes, so this is no problem.
>
Nothing pithy to add ... just that these are two different things! The
size of the directory IS 1024, the summed sizes of the contents of the
directory are 2MB plus. Technically accurate as it stands. But I agree
there are many cases (most?) when it would be best to think about
content size.
-
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/