Re: [prepatch] address_space-based writeback

[Denis Vlasenko]

On 30 April 2002 11:40, Keith Owens wrote:
> On Tue, 30 Apr 2002 23:15:23 +1000,
> john slee <[e-mail]> wrote:
> >probably because there is software out there relying on them being
> >numbers and being able to do 'if(inum_a == inum_b) { same_file(); }'
> >as appropriate.  i can't think of a use for such a construct other than
> >preserving hardlinks in archives (does tar do this?) but i'm sure there
> >are others
>
> Any program that tries to preserve or detect hard links.  cp, mv (files
> a and b are the same file).  tar, cpio, rsync -H, du, etc.
>
> The assumption that inode numbers are unique within a mount point is
> one of the reasons that NFS export does not cross mount points by
> default.  man exports, look for 'nohide'.

And I recently moved my /usr/src to separate partition.
That is, /usr/src is now a mount point.
I have to export it in NFS exports *and* mount it *on every workstation*
(potentially thousands of wks!).

I'll repeat myself. What if some advanced fs has no sensible way of 
generating inode? Does it have to 'fake' it, just like [v]fat does it now?
(Yes, vfat is not 'advanced' fs, let's not discuss it...)

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