[lkml]   [2002]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [prepatch] address_space-based writeback
    On Wednesday 01 May 2002 03:18 pm, Denis Vlasenko wrote:

    > The fact that minix,ext[23],etc has inode #s is an *implementation detail*.
    > Historically entrenched in Unix.
    > Bad:
    > inum_a = inode_num(file1);
    > inum_b = inode_num(file2);
    > if(inum_a == inum_b) { same_file(); }
    > Better:
    > if(is_hardlinked(file1,file2) { same_file(); }
    > Yes, new syscal, blah, blah, blah... Not worth the effort, etc...
    > lets start a flamewar...

    If I'm backing up a million files off of a big server, I don't want an
    enormous loop checking each and every one of them against each and every
    other one of them via some system call (potentially through the network) to
    go looking for dupes. I want some kind of index I can hash against on MY
    side of the wire to go "Have I seen this guy before?".

    That's EXACTLY what an inode is: a unique index for each file that can be
    compared to see if two directory entries refer to the same actual file.
    (Anything ELSE an inode is is an implementation detail, sure.)

    These kind of numeric identifiers show up all over the place. Process ids,
    user ids, filehandles... It's not an implementation detail, it's a sane API.

    Having them be persistent across reboots is only really needed for network
    exported filesystems (things like "tar" don't care). In theory, the clients
    could be informed of server reboots and resync when necessary (about like
    samba does). Of course there's a certain three-letter network server
    (originally from another three letter word) that tries to maintain no state
    whatsoever about its clients, when the entire JOB of a filesystem is
    basically to maintain persistent state...

    But we won't go there. And calculating whatever the heck your unique hash is
    entirely from your persistent data, in a reproducible way, generally isn't
    brain surgery...

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

     \ /
      Last update: 2005-03-22 13:25    [W:0.021 / U:17.368 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site