Subject: RE: [nfsv4] Reclaim bit for pNFS layout operations

From: "Halevy, Benny" <[email-masked]>
Date: Sat, 7 Jan 2006 10:03:52 -0500

>From the options you described I like option 2 the most as the server can
always verify the layout reclaimed by the client against sanity rules or
even against a persistently stored copy of the layout (like the one required
for option 1).  My question is whether this can be achieved without a new
operation but rather with LAYOUTCOMMIT with a reclaim bit.

In the recovery grace period the server would allow only LAYOUTCOMMITs
with the reclaim bit set and will disallow any LAYOUTGETs.

Benny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, January 06, 2006 23:48
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [nfsv4] Reclaim bit for pNFS layout operations

That's a fair statement.  Put another way, option 2 opens the
door for implementations that invest more trust in the client.
-Steve 

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Friday, January 06, 2006 4:43 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] Reclaim bit for pNFS layout operations

On Fri, Jan 06, 2006 at 04:10:07PM -0500, [email-masked] wrote:
> It was noted in discussion that this approach would require a significant
> level of trust to be invested in the client by the server.  It was further
> noted that the server could apply some level of sanity checking on the
> physical mapping provided by the client.  For instance, at a basic level
> the server could verify that the blocks included in the client mapping
> which correspond to provisional allocations are, in fact, free blocks in
> the file system.  If the sanity checks fail, the server could reject the
> LAYOUTRECLAIM operation.

So it doesn't look like option 2 *requires* the server to invest more
trust in the client--the server could still store the whole physical
mapping if it wanted to.  Option 2 just leaves the decision about how
much to trust the client up to the implementation.  Right?

--b.

_______________________________________________
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: Garth Goodson <[email-masked]>
Date: Mon, 09 Jan 2006 10:48:10 -0800

> with the reclaim bit set and will disallow any LAYOUTGETs.

I was thinking of this too.  At least in LAYOUTCOMMIT you have the 
layoutupdate field which can be used by the client to specify what it 
thinks the layout should be.  However, I think this might lead to a 
slight overloading of semantics.  The client is committing a layout it 
had, without getting a new layout.  My question is, what is the state of 
the layout on the client after the LAYOUTCOMMIT succeeds?  Does it hold 
the layout it just committed?

I guess the other alternative is a LAYOUTGET w/reclaim bit set, followed 
(immediately) but a LAYOUTCOMMIT for that layout (with the client's 
version thereof).

-Garth