Subject: RE: [nfsv4] Parallel open support

From: [email-masked]
Date: Tue, 19 Sep 2006 16:11:11 -0400 (EDT)

> To be clear, I'm talking about a stateid with say 96 bits
> that map map to the open_owner and lock_owner, and 32 bits to count
> up to 2^32 simultaneous open owners. This model then requires
> the server to share the following storage among all simultaneous
> OPENers of the 96 bit value:
> 
> - the 96 bit value
> - the count of the number of outstanding OPENers (increment on each
>   OPEN, decrement on each CLOSE)
> - the lowest outstanding uniquifier
> - the highest outstanding uniquifier

And if a client uses a Stateid mid way between lowest and highest uniquifier
after it has Closed that Stateid, how does the server know to return
NFS4ERR_BADSTATID?

You can add a bitmap for the range of lowest<->highest outstanding
uniquifier, but how do you set a bound on the size of that bitmap?
(other than 2^32 bits long)

rick

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

---

From: Mike Eisler <[email-masked]>
Date: Tue, 19 Sep 2006 13:48:23 -0700 (PDT)

> after it has Closed that Stateid, how does the server know to return

Good point, you're correct, the server doesn't know. In the
new world of exactly once semantics, I didn't imagine a client
would do that. If it does, then the server would need to keep
the reference count as a signed value, and if there is an
attempt to lower the reference count
to below zero (or if it goes to zero and there is
a period of idleness) the server tosses the 96 bit value of the
stateid, and the client has harmed itself (which it will see when
it uses stateid with the same upper 96 bits). I can live with that.
 
> (other than 2^32 bits long)

If you wanted to use a bit map (to save the client from
itself) instead of a 32 bit reference
count you'd use something with fewer bits. A 7 bit
bit reference counts uses 128 bits, equal to the memory for one
stateid.
As you detected an open_owner opening the same
file_handle twice, the bit map could be allocated then. At two openers,
you are using twice as much memory as NFSv4.0, but
at 3 or more you are amortizing costs. Once the
128th simulateous OPEN is reached, you allocate a fresh stateid,
and fresh 96 bit value.

I'm sure there are other ways; I mainly wanted to be convinced
economy was possible if we got rid of upgrade/downgrade.