Re: [nfsv4] Write-behind caching

[Trond Myklebust <[e-mail]>]

On Thu, 2010-11-04 at 20:46 -0400, [e-mail] wrote:
> > The multiple pNFS data servers can provide much higher 
> > throughput than the MDS, and hence it should be valid 
> > for a client to cache writes more aggressively when it 
> > has a layout because it can drain its dirty cache faster.
> 
> But the existing text suggests that this very situation, draining the
> dirty data using the layout, should (or might) result in less aggressive
> caching.  The fact that you are doing it in response to a recall means
> that you have a higher drain rate times a limited time, rather than a
> more limited drain rate times an unlimited time.
> 
> I think the question is about how you consider the case "if you cannot
> get the layout back".  If a client is allowed to do writes more
> efficiently despite the recall, why is not allowed to do reads more
> efficiently and similarly delay the recall?  It seems that the same
> performance considerations would apply.  Would you want the client to be
> able to read through the area in the layout in order to use it
> effectively?  I wouldn't think so.
> 
> I've proposed that this choice (the one about the write) be made the
> prerogative of the mapping type specifically.  For pNFS file, I would
> think that the normal assumption when a layout is being recalled is that
> this is part of some sort of restriping and that you will get it back
> and it is better to return the layout as soon as you can.

Writeback policy does not belong in the layout drivers. You may mandate
whatever you like in the spec, but please do realise that it will not be
implemented.

Trond