Re: [nfsv4] Write-behind caching

[Thomas Haynes <[e-mail]>]

References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AANLkTi=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BF3BB6!
 [e-mail]> <[e-mail]>
To: Trond Myklebust <[e-mail]>
X-Mailer: Apple Mail (2.1081)
Return-Path: [e-mail]
X-OriginalArrivalTime: 02 Nov 2010 16:50:30.0913 (UTC) FILETIME=[0F42DF10:01CB7AAE]


On Nov 2, 2010, at 9:18 AM, Trond Myklebust wrote:

> 
> * While this may lead to layout bouncing between clients and/or
> the server, the clients do have the option of detecting this,
> and choosing write through MDS to improve efficiency. Grabbing
> the layout, and blocking others from accessing the data while
> you write is not a scalable solution even if you do believe
> there is a valid scenario for this behaviour.


With multi-segment layouts, this makes me think of a really coarse
grained locking mechanism where client A grabs layout segment 1
for writing and client B grabs layout segment 2 for writing. 

Hmm, even without multiple "physical" segments (i.e., different DSes
behind the layouts), client A could ask for a layout for the first 1G
and client B could ask for a layout on the second 1G. client A
SHOULD not assume anything about the layout outside of the
range it has grabbed.

BTW - yes I have hijacked this thread for my own amusement and no,
I am not advocating clients take this approach.