Subject: RE: [nfsv4] pNFS - bad devices

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 2 Nov 2005 08:37:11 -0500

Well if this flag didn't exist, what should a client do after
returning the layout?

Try to get a new layout I would assume.  And if he got one, he would
be exactly where he wants to be.  

On the other hand if he didn't get it, he would have wasted one
RPC.  So if this flag existed, it would be a hint (if zero) telling
the client that it was likely he would not be able to reget the 
layout.  I think that would be helpful but it is a minor optimization.

-----Original Message-----
From: Halevy, Benny [mailto:[email-masked]]
Sent: Wednesday, November 02, 2005 6:14 AM
To: 'Marc Eshel'; Goodson, Garth
Cc: [email-masked]
Subject: RE: [nfsv4] pNFS - bad devices

In fact, there's no consistency related reason for the client to flush
any data in this scenario, and since layouts are orthogonal to cache
consistency a better approach for the client might be to return the
old layout and get a new one (can be in the same compound) while keeping
the dirty data in its cache and sync it later with the new layout
or via the MDS at the client's convenience.

This can be achieved by adding a flag to CB_LAYOUTRECALL indicating
that the layout is just invalidated - i.e. there's a good chance for the
client to get a new layout immediately after returning the current one.

Benny

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Marc Eshel
> Sent: Tuesday, November 01, 2005 9:22 PM
> To: Garth Goodson
> Cc: [email-masked]
> Subject: [nfsv4] pNFS - bad devices
> 
> 
> When one of the data server crashes the metadata server uses 
> CB_LAYOUTRECALL to recall all layouts that were included the now dead 
> node. The client will than go and try to commit its data to the dead 
> node(device) before returning the layout which will cause at 
> the minimum 
> big delays. Maybe we can add more information to the layout recall to 
> include either the list of bad devices (don't even try to do 
> I/O to those 
> devices) or just a way to advice the client to flush/commit 
> the data using 
> the MDS  to complete the recall.
> Marc. 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

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

---

From: Marc Eshel <[email-masked]>
Date: Wed, 2 Nov 2005 09:14:44 -0800

The draft suggest that the client might chose to flush dirty data before 
returning the layout, so I think that we do need the flag Benny suggested. 
Not only to get the new layout in one call and save an RPC, but more 
importantly tell the client NOT to flush using the old layout.
Marc.

---

From: Garth Goodson <[email-masked]>
Date: Wed, 02 Nov 2005 09:28:58 -0800

I think two types of recalls have been hit upon.  First, there is the 
'layout being recalled due to conflict, but the layout is not changing - 
flush dirty data using existing layout'.  Second, there is the 'layout 
recalled due to bad device - flush data through mds'.

My question is: do we need one or two flags?  One for 'flush through the 
MDS', and one for 'attempt to reget layout after recall is complete'. 
Or does one imply the other?  My preference is to be clear rather than 
overly concise.

-Garth

---

From: Marc Eshel <[email-masked]>
Date: Wed, 2 Nov 2005 10:02:26 -0800

Sure two flags will be even better.
Marc.