[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    [W:0.028 / U:8.860 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site