lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux NFS client problems with SGI server
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.315 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site