Re: [prepatch] address_space-based writeback

[Rob Landley]

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