[pnfs] page sync model

[Benny Halevy]

On Apr. 03, 2008, 17:11 +0300, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> On Thu, 2008-04-03 at 16:42 +0300, Benny Halevy wrote:
>> On Apr. 03, 2008, 15:03 +0300, Benny Halevy <bhalevy.lists at gmail.com> wrote:
>>> Image updated and saved as gif (looks better)
>>> http://www.bhalevy.com/pnfs/pnfs-page-sync-model.gif
>> or even better
>> http://www.bhalevy.com/pnfs/pnfs-page-sync-model.pdf
> 
> There are plenty of 'fail' loops in that graph. In those cases, how do
> you decide which method to try next, and when do you decide to give up?

That's an important thing to define.
In general I'd say that the decision should be made based on:
- what failed
- why it failed
- is the error transient or permanent.

The analysis and recommendation should be up to the layout-driver
since it knows best what exactly happened.

Now, regarding what to try next: if the layout driver recommended
retrying with pNFS we should attempt to get a new layout (for simplicity
reasons I think we should always refresh the layout, although it might
not be strictly necessary in all cases).  If we failed to get the layout
then if the error is permanent we plan to mark the _inode_ with
NFS_INO_LAYOUT_FAILED which will avoid pNFS on that inode (until it's
evicted from memory).  Otherwise, if the error is transient we suspend
layout get on the inode and retry later (this is currently implemented
in a rather naive way in pnfs_get_layout_done()).
The number of retries over pNFS could be determined by the layout driver
(e.g. some layout drivers would like to retry the pNFS forever forever
as long as the errors are transient)

Benny

> 
> Trond
> 
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs