Re: [nfsv4] locks associated with close

cburnett@us.ibm.com

Subject: Re: [nfsv4] locks associated with close
Message-ID: <OFA3CE9478.1AD0AE1C-ON87256D1A.0074BF6C@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Fri, 2 May 2003 16:20:48 -0500

Thanks for the clarification Spencer. If CLOSE gets a stateid other than 
an "open" stateid, is the correct error return NFS4_BAD_STATEID?

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

Spencer Shepler <spencer.shepler@sun.com>
Sent by: nfsv4-admin@ietf.org
05/02/2003 03:35 PM
Please respond to spencer.shepler

        To:     nfsv4@ietf.org
        cc: 
        Subject:        Re: [nfsv4] locks associated with close

On Fri, Carl Burnett wrote:
> 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.

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 Shepler <spencer.shepler@sun.com>
> Sent by: nfsv4-admin@ietf.org
> 05/02/2003 02:49 PM
> Please respond to spencer.shepler
> 
> 
>         To:     nfsv4@ietf.org
>         cc: 
>         Subject:        Re: [nfsv4] locks associated with close
> 
> 
> 
> On Fri, rick@snowhite.cis.uoguelph.ca 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
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> 
> 

-- 
Spencer

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4