Subject: RE: [nfsv4] Proposal for adding reclaim bit to pNFS COMMITLAYOUT

From: [email-masked]
Date: Fri, 27 Jan 2006 12:42:13 -0500

Actually, we do need to wait until the grace period is over---at least
for the block/volume case.  The reason being, the meta-data server has
no knowledge about the provisional allocation from prior to the crash
(unless this information was made persistent). If the server were to
allow write operations during the grace period, it could potentially
re-use blocks which had previously been part of the provisional
allocation for some client's layout, and which contain good data which
the client will try to commit using the "reclaim commit".  If this re-use
happens, the client will lose its writes.

So, unless we require the server to make provisional allocation
persistent, we will need to wait until the grace period is over to
allow dirty data writes.

One other point---isn't this already a requirement of NFSv4?  During
the grace period, aren't writes disallowed due to potential conflicts
with locks that have yet to be reclaimed?
-Steve

-----Original Message-----
From: William A.(Andy) Adamson [mailto:[email-masked]] 
Sent: Friday, January 27, 2006 9:07 AM
To: Brent Welch
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nfsv4] Proposal for adding reclaim bit to pNFS COMMITLAYOUT 

[email-masked] said:
> Instead of reclaiming a layout with LAYOUTGET, a client can attempt to
commit
> data written before the file server crash by setting a reclaim bit on the
> LAYOUTCOMMIT operation.  This should only be done for data that the client
> has already written using a layout obtained before the server restart.
For
> data still dirty in the client memory, the client should get a new layout
> segment after the server's grace period has elapsed.  Alternatively, the
> client can write that data through the metadata server. 
> Note that the
> meta-data server will not allow any operations that could potentially
change
> the state of the file-system during the recovery grace period. Thus
getting
> a new pNFS layout and writing of dirty data must wait until the recovery
> grace period is over.  

the last sentence is unclear - writing of dirty data does not have to wait 
until the recovery grace period is over, as suggested, the client can
recover 
the OPEN(write) and write the dirty data through the meta-data server a la 
v4.0.

so change 

"Thus getting a new pNFS layout and writing of dirty data must wait until
the 
recovery grace period is over. "

to  

"Thus getting a new pNFS layout and writing of dirty data via the data
storage 
protocol must wait until the recovery grace period is over."

-->Andy

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 27 Jan 2006 12:47:05 -0500

> with locks that have yet to be reclaimed?

I think that should only be the case with special-stateid-writes or
writes to files that may have mandatory locking in force.

If a write is performed with a "real" stateid (derived from an open)
then we know it can't conflict with a still-to-be-reclaimed open
(otherwise the open couldn't legitimately have been reclaimed), so the
only possible conflict is with a mandatory lock.

--b.