On Thu, 02 Oct 2008 12:56:53 +0200, Frank Batschulat (Home) <Frank.Batschulat
at Sun.COM> wrote:
> 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.
looking further into this it appears that the client ignores the the plain
result of the OTW GETATTR call as hinted by nfs4getattr()
943 /*
944 * If we've got cached attributes, we're done, otherwise go
945 * to the server to get attributes, which will update the cache
946 * in the process. Either way, use the cached attributes for
947 * the caller's vattr_t.
948 *
949 * Note that we ignore the gar set by the OTW call: the attr
caching
950 * code may make adjustments when storing to the rnode, and we
want
951 * to see those changes here.
952 */
[...]
956 if (!ATTRCACHE4_VALID(vp)) {
957 mutex_exit(&rp->r_statelock);
958 error = nfs4_getattr_otw(vp, &gar, cr, 0);
959 mutex_enter(&rp->r_statelock);
960 }
961
962 if (!error)
963 *vap = rp->r_attr;
the attribute caching code itself does not do any adjustements as far as I can
see
wrt. to the 'fsid' value of the vattr struct it got from the server, it makes
some
adjustements to size etc....but not to the 'fsid' thats why I can not see how
that
should differ from the underlaying file systems 'fsid' on the server.
---
frankB
