Messages in this thread | | | From | (Peter Benie) | Subject | Re: Linux NFS client problems with SGI server | Date | Sat, 17 Jul 1999 11:29:27 +0100 |
| |
Erik Mouw writes ("Re: Linux NFS client problems with SGI server"): > > So can you explain why it actually *does* work on IRIX and SunOS/Solaris > clients? If they made a workaround, why can't we implement a similar one > in Linux?
From Linux's behaviour, I would guess that it looks up inode data by inode number. This will not work with filesystems that reuse inode numbers (eg. nohide or NetApp .snapshot). One of the many problems with NFS is that to use it with Unix, it needs to provide inode numbers. The 'obvious' mapping onto inode numbers is to use fileids, however, the server only guarantees to ensure that the tiple (fsid,fileid) is unique. Consequently, if you export multiple filesystems, you _will_ break Posix semantics, and you may cause other problems. If you try 'cp .snapshot/hourly.0/myfile myfile' and you'll get ".snapshot/hourly.0/myfile and myfile are the same file", even if the contents are different.
To avoid breaking completely, Linux should not use the inode number to look up inode data.
To avoid duplicate (dev,inode) pairs, Linux could keep track of which fsids a server was exporting and automatically allocate a new device number when required. (This functionality belongs in mountd, but it's way to late to fix that.)
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |