Re: [prepatch] address_space-based writeback

Rob Landley
2002-05-03T20:47:23Z

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