[AFS3-std] Re: byte-range file locking draft

[Andrew Deason]

On Thu, 6 May 2010 15:06:54 -0400 (EDT)
"Matt W. Benjamin" <matt@linuxbox.com> wrote:

> The intention is to indicate that a lock is really a lease from the
> server, not to encourage the server to be capricious in recalling
> locks.  Perhaps there's some grace concept missing when certain types
> of locks are outstanding, however?  The delegation concept did provide
> for this.

Yeah, I didn't mean to say the draft is implying they'll be revoked
often; I'm just wondering what our failure mode is. I don't see how you
can really avoid unhappiness: say you fcntl() lock, write(), fsync(),
and write() again. If the lock gets revoked for whatever reason between
the fsync() and the write()... it seems like you're screwed no matter
what you do.

But if we return errors the second write (and subsequent accesses) or
something, perhaps we only do as badly as a disk crash?

> > Also, what interfaces have atomic lock upgrades? I thought POSIX
> > ones didn't, but perhaps I'm remembering incorrectly... or are there
> > Windows ones that have this?
> 
> I think a subset of POSIX interfaces does assume it, see OpenGroup
> 2004's description fcntl.  The situation with Windows is I think more
> complicated, there may need to be a note on it.  

Everything I've read from them seems... vague.

>>> Before a successful return from an F_SETLK or an F_SETLKW request
>>> when the calling process has previously existing locks on bytes in
>>> the region specified by the request, the previous lock type for each
>>> byte in the specified region shall be replaced by the new lock type.

-- 
Andrew Deason
adeason@sinenomine.net