Messages in this thread |  | | From | Denis Vlasenko <> | Subject | Re: [prepatch] address_space-based writeback | Date | Wed, 1 May 2002 17:18:32 -0200 |
| |
On 30 April 2002 11:40, Keith Owens wrote: > On Tue, 30 Apr 2002 23:15:23 +1000, > john slee <indigoid@higherplane.net> 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 - 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/
|  |