lkml.org 
[lkml]   [1999]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans