Re: [nfsv4] Write-behind caching

[Trond Myklebust <[e-mail]>]

On Fri, 2010-10-29 at 17:48 -0400, Trond Myklebust wrote:
> On Fri, 2010-10-29 at 17:32 -0400, sfaibish wrote:
> > On Fri, 29 Oct 2010 13:39:55 -0400, Trond Myklebust  
> > <[e-mail]> wrote:
> > 
> > > On Fri, 2010-10-29 at 13:20 -0400, [e-mail] wrote:
> > >> There are two issues here with regard to handling of layout recall.
> > >>
> > >> One is with regard to in-flight IO.  As Benny points out, you cannot be  
> > >> sure that the in-flight IO can be completed in time to avoid the MDS  
> > >> losing patience.  That should rarely be the case though, if things are  
> > >> working right.  The client has to be prepared to deal with IO failures  
> > >> due to layout revocation.  Any IO that was in flight and failed because  
> > >> of layout revocation will need to be handled by being reissued to the  
> > >> MDS.  Is there anybody that disagrees with that?
> > >>
> > >> The second issue concerns IO not in-flight (in other words, not IO's  
> > >> yet but potential IO's) when the recall is received.  I just don't see  
> > >> that it reasonable to start IO's using layout segments being recalled  
> > >> (whether for dirty buffers or anything else).  Doing IO's to the MDS is  
> > >> fine but there is no real need for the layout recall to specially  
> > >> trigger them, whether clora_changed is set or not.
> > >
> > > This should be _very_ rare. Any cases where 2 clients are trying to do
> > > conflicting I/O on the same data is likely to be either a violation of
> > > the NFS cache consistency rules, or a scenario where it is in any case
> > > more efficient to go through the MDS (e.g. writing to adjacent records
> > > that share the same extent).
> > Well this is a different discussion: what was the reason for the recall in
> > the first place. This is one usecase but there could be other usecases
> > for the recall and we discuss here how to implement the protcol more than
> > how to solve a real problem. My 2c
> 
> I strongly disagree. If this is an unrealistic scenario, then we don't
> have to care about devising an optimal strategy for it. The 'there could
> be other usecases' scenario needs to be fleshed out before we can deal
> with it.

To clarify a bit what I mean: we MUST devise optimal strategies for
realistic and useful scenarios. It is entirely OPTIONAL to devise
optimal strategies for unrealistic ones.

If writing back all data before returning the layout causes protocol
issues because the server cannot distinguish between a bad client and
one that is waiting for I/O to complete, then my argument is that we're
in the second case: we don't have to optimise for it, and so it is safe
for the server to assume 'bad client'...

   Trond