Messages in this thread |  | | From | Rob Landley <> | Subject | Re: [prepatch] address_space-based writeback | Date | Fri, 3 May 2002 10:48:50 -0400 |
| |
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...
Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |