Messages in this thread | | | From | Denis Vlasenko <> | Subject | Re: [prepatch] address_space-based writeback | Date | Sat, 4 May 2002 22:42:23 -0200 |
| |
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. [snip]
I agree. API is not insane, but I wouldn't call it wonderful too. -- vda - 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/
| |