On Thu, 02 Oct 2008 12:42:39 +0200, Nils Goroll <slink at schokola.de> wrote:
> >> [...] When I run the attached program on 3 >>> different hosts, I get the same st_ino values but 3 >>> different st_dev values. In one case, the file is ufs >>> mounted since that host is actually connected to the >>> hard drive. In the other two, the file is nfs mounted. >> >> now our NFS server on request just issues a VOP_GETATTR() into the >> underlaying file system >> (eg. UFS) and delivers back to the client what it got from there. > > Agree. > > But isn't the device id of the NFS *client* what is being returned in st_dev? > I > would not know a reliable way how to ensure that this is equal across several > hosts. > > My recommendation for the implementation is to assume that a particular mount > point path is always the same share across the hosts (for example assign ids > to > paths in a config file) and to use st_ino together with that information to > generate a unique file identifier. the NFS client code just makes an OTW GETATTR call and does deliver the result back to the caller application on the client without any further ado and mucking around with the 'fsid' field in the vattr struct. the NFS server code on the other hand just passed that GETATTR request down to the underlaying file system with VOP_GETATTR(), and again it does cram the resulting vattr struct into the the RPC response without any further mucking around with the 'fsid' in the vattr struct it retrieved from ufs_getattr(). the stat(2) system call on the client will eventually translate the vattr 'fsid' into the st.st_dev field. thus as it stands, the assumption that st.dev must be the same for the cases described by the customer, ie NFS client_A -> NFS server_A -> UFS_A => dev_A NFS client_B -> NFS server_A -> UFS_A => dev_B local access -> UFS_A => dev_C is valid as I think, getting 3 different st_dev values here for the same underlaying device hosting the file seems bogus to me. --- frankB
