[lkml]   [1999]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: generalizing . and ..

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean