Subject: RE: [NFSv4] Hints for client on LAYOUTRECALL

From: [email-masked]
Date: Thu, 10 Aug 2006 15:56:57 -0400

Yes, this is definitely an issue.  In the blocks/volume draft we said
that layouts which conflict with mandatory file locks or share reservations
should not be granted, and should be recalled before granting such locks.

So for example, suppose we have a 4k block size, and client A has an
excl byte-range lock from 0 to 2k in a file, and client B asks for a
layout which covers bytes 0K to 12K-1 in the same file.  Layouts returned
by the server will always be block-aligned, so client B's request will
either
be rejected or shortened so that the layout returned is 4k to 12k-1.
Application writes to the first block of the file must therefore be routed
to the meta-data server.  Also, the standard v4 rules for caching in the
presence of mandatory locks should prevent the client from trying to issue
a full cache-block write for the first block.

Having said that, we still need to do a thorough review of these scenarios
to be sure we haven't missed something...  

-Steve

On Wed, 09 Aug 2006 10:56:29 -0400, Trond Myklebust wrote:
> Note that there are several cases where the blocks world gets
> "interesting" w.r.t. the NFS caching model.
> 
> For instance any operation where cache consistency _is_ important (e.g.
> the client holds a byte range lock for a write that is not block/extent
> aligned) and which requires a read-modify-write in order to succeed is
> problematic. I'd suggest that clients should probably do this using the
> metadata server, which can recall outstanding layouts on the affected
> region in order to enforce atomicity.
> 
> Is this sort of scenario discussed in the latest blocks draft?
> 
> Cheers,
>   Trond

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4