[plug] Linux NFS client to Solaris HSM NFS server

[Ian Kent]

Hi all,

I have an NFS access problem with a Redhat 7.1 client using a 2.4.4 kernel
with Tronds' NFS V3 patches, connecting to a Solaris HSM NFS server. Mount
is version 2.10r and nfs-utils is 0.3.1.

On the HSM NFS server I using SAM-fs version 3.3.1 from LSC with Solaris
2.6.

SAM-fs is a hierarchical storage management (HSM) system for Solaris. It
provides a virtual filesystem that resides on primary storage (magnetic
disk) and secondary storage (typically magnetic tape or optical disk)

When files are written into the HSM filesystem they are written
immediately to the primary storage (disk) and then after a short period of
time to secondary storage. If the system reaches a point where it starts
to run out of space on the primary (cache) disk, it removes the data
portion of the file from the cache leaving the copy on secondary storage.
The file is said to be 'offline'.

When this happens, the directory entry for the file remains in place. As
such the file is still visible to 'ls', 'find' and all the usual directory
level tools. However, if an application tries to open an 'offline' file,
the open operation is blocked while the HSM system retieves the file data
from the secondary media and puts it back on the disk cache. The
application is then passed the data.

On Solaris NFS clients this process is seamless. The client blocks until
the file data is available and then continues with no further interaction
from the user/application required. In interactive sessions. a message
appears in the parent shell saying.

"file temporarily unavailable on the server, retrying... "

It is unclear whether this message is actually passed verbatim from the
server to the client or whether a response code from the server triggers
the client to generate the message for the user.

My problem is that attempting to access a samfs file which is offline (ie
not present on disk, but archived to tape) the Linux client issues the
error:

error:read failed: Input/output error (5)

plus other errors relating to the command used.

On a Solaris client the same request with block until the samfs file comes
online (ie brough in from tape) and then carry on.

I have tried sync vs async and tcp vs udp mount options without any change
in error response.

Looking at tcpdump output I get get the impression that the client is
receiving an unknown response and is returning the I/O error as a last
chance response.

Can anyone help with this. I can provide tcpdump files if needed.

Ian Kent