Re: out of order v3 write replies and cache invalidation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 30, 2016 at 2:39 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> On Wed, Mar 30, 2016 at 2:20 PM, Trond Myklebust
> <trond.myklebust@xxxxxxxxxxxxxxx> wrote:
>> On Wed, Mar 30, 2016 at 1:40 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>>> If we assume no other writers until we close, couldn't you on close wait
>>> for all writes, send a final getattr for change attribute, and trust
>>> that?  If the extra getattr's too much, then you'd need some algorithm
>>> like the above to determine which change attribute is the last.  Or
>>> implement
>>> https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41#section-12.2.3
>>> on client and server and just track the maximum returned value when the
>>> server returns something other than NFS4_CHANGE_TYPE_IS_UNDEFINED.
>>>
>>
>> The correct tool to use for resolving these caching issues is
>> ultimately a write delegation.
>>
>> You can also eliminate a lot of invalidations if you know that the
>> server implements change_attr_type ==
>> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER or
>> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS, since that allows you to
>> predict what the attribute should be after a change.
>
> Thanks for all the info. But let me highlight that I was asking about
> v3. I don't see that the code has issues with cache invalidation for
> nfsv4 when receiving out-of-order RPCs.
>
> I am not sure if it's worth implementing something that Bruce
> suggests. I just wanted to make sure that what i'm seeing is
> "expected" behavior (caz it's v3) and not a bug.

Yes. The design does expect the occasional false positive cache
invalidation due to RPC request reordering.

Cheers
 Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux