Messages in this thread | | | Date | Sun, 27 Jun 1999 11:40:36 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: 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/
| |