[lkml]   [2002]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [prepatch] address_space-based writeback
On 3 May 2002 12:48, Rob Landley 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?".

You can check pairs of files with same size,mode,etc and with hardlink
count>1. That will dramatically reduce number of is_hardlinked() calls
(unless you construct a pathological case of 1000000 hardlinks to
single file).

> 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.

I agree. API is not insane, but I wouldn't call it wonderful too.
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.087 / U:0.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site