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