Subject: Re: [nfsv4] locks associated with close

From: Carl Burnett <[email-masked]>
Date: Fri, 2 May 2003 15:08:28 -0500

Spencer,

Would it be correct to say that,

Normally, the stateid supplied in CLOSE should represent an open owner 
because the client should have already released all held locks. If the 
state id represents a lock owner, then it should really not have any held 
locks underneath it. If it does (regardless of whether the stateid 
represents an open owner or a lock owner), the server is allowed to return 
an error.

In the end the server must be capable of accepting a stateid that 
represents either an open owner (stateid obtained at OPEN) or a lock owner 
(obtained in LOCK) in a CLOSE operation.

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

Spencer Shepler <[email-masked]>
Sent by: [email-masked]
05/02/2003 02:49 PM
Please respond to spencer.shepler

        To:     [email-masked]
        cc: 
        Subject:        Re: [nfsv4] locks associated with close

On Fri, [email-masked] wrote:
> I think I've got most of the stateid stuff figured out, but I'm still
> stymied w.r.t. what locks are referred to by the open_stateid provided
> to close. The spec. notes that it should either free the locks or
> return an error if there are outstanding locks, but which locks are 
these?

The locks established by the LOCK operation.

> My understanding (which could be wrong:-) is that a lock_owner is
> distinct from an open_owner. Is there still an association between a
> lock_owner and open_owner? Is it formed by the open_to_lock_owner4 case
> for the lock op? (In other words, are all locks on all lock_owners that
> were gotten by the open_to_lock_owner4 case for lock ops on the given
> open_stateid the locks CLOSE is referring to?)

lock_owner and open_owner are distinct but an association is created
at LOCK via the open_to_lock_owner4 as you suggest.  That data
structure associates to an open_owner by providing the open_stateid
(which also represents the open file).  Are you further correct in
that when CLOSE is processed the open_stateid provided to it is the
"parent" of the individual file locks that have been associated with
the file via the open_to_lock_owner4.  Ideally, the client will have
released/LOCKU all the file locks at the point of CLOSE.

-- 
Spencer

_______________________________________________
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: Spencer Shepler <[email-masked]>
Date: Fri, 2 May 2003 15:35:38 -0500

> (obtained in LOCK) in a CLOSE operation.

This is not correct.  The .x file was changed in the past in an
attempt to make this clearer but...  The only stateid acceptable to
CLOSE is a stateid obtained from OPEN, OPEN_CONFIRM, or
OPEN_DOWNGRADE.

-- 
Spencer