fcntl(F_GETLEASE) semantics??

fcntl(F_GETLEASE) semantics??

[Peter Chubb]

Hi,
	The LTP test fcntl23 is failing.  It does, in essence, 
	fd = open(xxx, O_RDWR|O_CREAT, 0777);
	if (fcntl(fd, F_SETLEASE, F_RDLCK) == -1)
	   fail;

fcntl always returns EAGAIN here.  The manual page says that a read
lease causes notification when `another process' opens the file for
writing or truncates it.  The kernel implements `any process'
(including the current one).

Which semantics are correct?  Personally I think that what the kernel
implements is correct (you can't get a read lease unsless there are no
writers _at_ _all_)


-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: fcntl(F_GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 09:48 (+1000) skreiv Peter Chubb:
> Hi,
> 	The LTP test fcntl23 is failing.  It does, in essence, 
> 	fd = open(xxx, O_RDWR|O_CREAT, 0777);
> 	if (fcntl(fd, F_SETLEASE, F_RDLCK) == -1)
> 	   fail;
> 
> fcntl always returns EAGAIN here.  The manual page says that a read
> lease causes notification when `another process' opens the file for
> writing or truncates it.  The kernel implements `any process'
> (including the current one).
> 
> Which semantics are correct?  Personally I think that what the kernel
> implements is correct (you can't get a read lease unsless there are no
> writers _at_ _all_)

A read lease should mean that there are no writers at all.

If we were to allow the current process to open for write, then that
would still mean that nobody else can get a lease. In effect you have
been granted a lease with exclusive semantics (i.e. a write lease). You
might as well request that instead of pretending it is a read lease.

Cheers,
  Trond

Re: fcntl(F_GETLEASE) semantics??

[Peter Chubb]

>>>>> "Trond" == Trond Myklebust <trond.myklebust@fys.uio.no> writes:

Trond> to den 11.08.2005 Klokka 09:48 (+1000) skreiv Peter Chubb:
>> Hi, The LTP test fcntl23 is failing.  It does, in essence, fd =
>> open(xxx, O_RDWR|O_CREAT, 0777); if (fcntl(fd, F_SETLEASE, F_RDLCK)
>> == -1) fail;
>> 
>> fcntl always returns EAGAIN here.  The manual page says that a read
>> lease causes notification when `another process' opens the file for
>> writing or truncates it.  The kernel implements `any process'
>> (including the current one).
>> 
>> Which semantics are correct?  Personally I think that what the
>> kernel implements is correct (you can't get a read lease unsless
>> there are no writers _at_ _all_)

Trond> A read lease should mean that there are no writers at all.

Trond> If we were to allow the current process to open for write, then
Trond> that would still mean that nobody else can get a lease. In
Trond> effect you have been granted a lease with exclusive semantics
Trond> (i.e. a write lease). You might as well request that instead of
Trond> pretending it is a read lease.

So the manual page is wrong.  Fine.


-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: fcntl(F GETLEASE) semantics??

[Michael Kerrisk]

> Von: Peter Chubb <peterc@gelato.unsw.edu.au>
> 
> >>>>> "Trond" == Trond Myklebust <trond.myklebust@fys.uio.no> writes:
> 
> Trond> to den 11.08.2005 Klokka 09:48 (+1000) skreiv Peter Chubb:
> >> Hi, The LTP test fcntl23 is failing.  It does, in essence, fd =
> >> open(xxx, O_RDWR|O_CREAT, 0777); if (fcntl(fd, F_SETLEASE, F_RDLCK)
> >> == -1) fail;
> >> 
> >> fcntl always returns EAGAIN here.  The manual page says that a read
> >> lease causes notification when `another process' opens the file for
> >> writing or truncates it.  The kernel implements `any process'
> >> (including the current one).
> >> 
> >> Which semantics are correct?  Personally I think that what the
> >> kernel implements is correct (you can't get a read lease unsless
> >> there are no writers _at_ _all_)
> 
> Trond> A read lease should mean that there are no writers at all.
> 
> Trond> If we were to allow the current process to open for write, then
> Trond> that would still mean that nobody else can get a lease. In
> Trond> effect you have been granted a lease with exclusive semantics
> Trond> (i.e. a write lease). You might as well request that instead of
> Trond> pretending it is a read lease.
> 
> So the manual page is wrong.  Fine.

No.  The behavior in Linux recently, and arbitrarily (IMO) changed:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111502547506310&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=111755426027086&w=2

One of the developers of the file leases mechanism seems to have 
agreed that this change should not have occurred:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111512619520116&w=2

but the suggested patch did not (yet) make its way into the kernel.

Stephen -- what is your take on this now?

Cheers,

Michael

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 10:14 (+0200) skreiv Michael Kerrisk:

> No.  The behavior in Linux recently, and arbitrarily (IMO) changed:

The change was NOT arbitrary. It was deliberate and for the reasons
stated.

The whole point of leases is to support CIFS oplocks for Samba and NFSv4
delegations in the kernel. Both have the same specific expected
behaviour.
The original deviates from that expected behaviour by allowing you to
get a shared lease when in a condition that does not allow actual
sharing.

Cheers,
  Trond

Re: fcntl(F GETLEASE) semantics??

[Michael Kerrisk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2990 bytes --]

> Von: Trond Myklebust <trond.myklebust@fys.uio.no>
> to den 11.08.2005 Klokka 10:14 (+0200) skreiv Michael Kerrisk:
> 
> > No.  The behavior in Linux recently, and arbitrarily (IMO) changed:
> 
> The change was NOT arbitrary. 

Okay -- I'm puzzled.  Two of the people that I understand to have
had a strong interest in file leases seemed to think the change 
shouldn't have occurred:

Stephen Rothwell: 
http://marc.theaimsgroup.com/?l=linux-kernel&m=111512619520116&w=2

    Thanks for the testing.  My expectation is that it shouldn't 
    matter how the current process opened the file for either 
    type of lease.  However, you are right (IMHO) that the current 
    process should *not* be counted as a writer in the case of 
    trying to obtain a F_RDLCK lease.

And Stephen suggested a one line patch to fix the problem

Matthew Wilcox also wrote:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111512898520775&w=2

    On Tue, May 03, 2005 at 09:55:42AM -0400, William A.(Andy) 
    Adamson wrote:
    > i believe the current implementation is correct. opening a 
    > file for write means that you can not have a read lease, 
    > caller included.

    Why not?  Certainly, others will not be able to take out a 
    read lease, so there's very little point to only having a 
    read lease, but I don't see why we should deny it.

(By the way, I wrote the fcntl.2 manpage text for file 
leases -- because there was no existing documentation, or 
specification of the desired behavior; the text was based 
on my experiments, and some email discussions with Stephen 
Rothwell.)

And I pointed out that the existing behaviour (which is 
still current in 2.6.13-rc4) is inconsistent:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111511455406623&w=2

    Some further testing showed the following (both open() 
    and fcntl(F_SETLEASE) from same process):

     open()  |  lease requested
      flag   | F_RDLCK  | F_WRLCK
    ---------+----------+----------
    O_RDONLY | okay     |  okay
    O_WRONLY | EAGAIN   |  okay
    O_RDWR   | EAGAIN   |  okay

In other words, a process can open a file read-write, and
can't place a read lease, but can place a write lease!  
That does not seem to make any sense to me.

> It was deliberate and for the reasons
> stated.

Can you elaborate -- which reasons are you referring to?  

> The whole point of leases is to support CIFS oplocks for Samba and NFSv4
> delegations in the kernel. 

Yep, I understand that much.

> Both have the same specific expected
> behaviour.
> The original deviates from that expected behaviour by allowing you to
> get a shared lease when in a condition that does not allow actual
> sharing.

And I should add -- I know little about SAMBA or CIFS.  But from 
what I've seen (the quoted messages above), the change seems to 
have been accidental, and inconsistent.

Cheers,

Michael

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 14:27 (+0200) skreiv Michael Kerrisk:
> And I pointed out that the existing behaviour (which is 
> still current in 2.6.13-rc4) is inconsistent:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111511455406623&w=2
> 
>     Some further testing showed the following (both open() 
>     and fcntl(F_SETLEASE) from same process):
> 
>      open()  |  lease requested
>       flag   | F_RDLCK  | F_WRLCK
>     ---------+----------+----------
>     O_RDONLY | okay     |  okay
>     O_WRONLY | EAGAIN   |  okay
>     O_RDWR   | EAGAIN   |  okay
> 
> In other words, a process can open a file read-write, and
> can't place a read lease, but can place a write lease!  
> That does not seem to make any sense to me.

Then what do you think that leases are supposed to do, and why?

AFAIK, the whole point here is to provide a method to allow CIFS and
NFSv4 clients to be notified if there is some behaviour on the server
that screws with the ability to cache data.

An exclusive (i.e. write) lease should mean that _nothing_ other than
your process is accessing the file. A client may cache the file data,
metadata and read/write locks because nobody else can change that
information, and nobody else holds locks on the file. It may also cache
file acl/access information, and hence cache new OPEN calls.

A shared (i.e. read) lease means that there are currently no processes
that can change the data or metadata (including your own). A client may
cache data, metadata and read locks since there are no writers, and
there is nobody holding write locks. The client may again cache OPEN
calls as long as they are read-only.

Note that the kernel is still incomplete w.r.t. notification of changes.
Holders of the oplocks/delegations need to be notified if the file is
renamed, or if the acl/access information changes, say.

Cheers,
  Trond

Re: fcntl(F GETLEASE) semantics??

[Michael Kerrisk]

Trond,

> Von: Trond Myklebust <trond.myklebust@fys.uio.no>
>
> to den 11.08.2005 Klokka 14:27 (+0200) skreiv Michael Kerrisk:
> > And I pointed out that the existing behaviour (which is 
> > still current in 2.6.13-rc4) is inconsistent:
> > 
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=111511455406623&w=2
> > 
> >     Some further testing showed the following (both open() 
> >     and fcntl(F_SETLEASE) from same process):
> > 
> >      open()  |  lease requested
> >       flag   | F_RDLCK  | F_WRLCK
> >     ---------+----------+----------
> >     O_RDONLY | okay     |  okay
> >     O_WRONLY | EAGAIN   |  okay
> >     O_RDWR   | EAGAIN   |  okay
> > 
> > In other words, a process can open a file read-write, and
> > can't place a read lease, but can place a write lease!  
> > That does not seem to make any sense to me.
> 
> Then what do you think that leases are supposed to do, and why?

As noted already, I don't know much of CIFS and SAMBA.
But are you saying that it is sensible and consistent that
"a process can open a file read-write, and can't place a 
read lease, but can place a write lease"?  

> An exclusive (i.e. write) lease should mean that _nothing_ other than
> your process is accessing the file. A client may cache the file data,
> metadata and read/write locks because nobody else can change that
> information, and nobody else holds locks on the file. It may also cache
> file acl/access information, and hence cache new OPEN calls.
> 
> A shared (i.e. read) lease means that there are currently no processes
> that can change the data or metadata (including your own). 
                                        ^^^^^^^^^^^^^^^^^

This is precisely the point of the problem.  Stephen 
Rothwell, and Matthew Wilcox seem to be saying that
the last bit is not the case.  

Cheers,

Michael

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 15:22 (+0200) skreiv Michael Kerrisk:

> As noted already, I don't know much of CIFS and SAMBA.
> But are you saying that it is sensible and consistent that
> "a process can open a file read-write, and can't place a 
> read lease, but can place a write lease"?  

It is just as "sensible and consistent" as being able to open the file
read-write and being able to place a read lease but not a write lease.
What is your point?

Make no mistake: this is not a locking protocol. It is implementing
support for a _caching_ protocol.

> This is precisely the point of the problem.  Stephen 
> Rothwell, and Matthew Wilcox seem to be saying that
> the last bit is not the case.  

The NFSv4 spec explicitly states that

  When a client has a read open delegation, it may not make any changes
  to the contents or attributes of the file but it is assured that no
  other client may do so.  When a client has a write open delegation,
  it may modify the file data since no other client will be accessing
  the file's data.  The client holding a write delegation may only
  affect file attributes which are intimately connected with the file
  data:  size, time_modify, change.

so NFSv4 cannot currently support this behaviour. If CIFS supports it,
then maybe we have a case for going to the IETF and asking for a
clarification to implement the same behaviour in NFSv4.

Cheers,
  Trond

Re: fcntl(F GETLEASE) semantics??

[Stephen Rothwell]

On Thu, 11 Aug 2005 15:22:39 +0200 (MEST) "Michael Kerrisk" <mtk-lkml@gmx.net> wrote:
>
> > A shared (i.e. read) lease means that there are currently no processes
> > that can change the data or metadata (including your own). 
>                                         ^^^^^^^^^^^^^^^^^
> 
> This is precisely the point of the problem.  Stephen 
> Rothwell, and Matthew Wilcox seem to be saying that
> the last bit is not the case.  

Sorry, Michael, I was not aware of why the change was made and I must
defer to Trond (for NFSv4) and the CIFS team on the appropriate semantics
here.  Matthew may have another opinion.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 10:06 (-0400) skreiv Trond Myklebust:

> The NFSv4 spec explicitly states that
> 
>   When a client has a read open delegation, it may not make any changes
>   to the contents or attributes of the file but it is assured that no
>   other client may do so.  When a client has a write open delegation,
>   it may modify the file data since no other client will be accessing
>   the file's data.  The client holding a write delegation may only
>   affect file attributes which are intimately connected with the file
>   data:  size, time_modify, change.
> 
> so NFSv4 cannot currently support this behaviour. If CIFS supports it,
> then maybe we have a case for going to the IETF and asking for a
> clarification to implement the same behaviour in NFSv4.

Note: I'm not saying that this means we _must_ implement the current
behaviour in leases. If CIFS allows the server to hand out read oplocks
when the client opened the file with a write share, then NFSv4 can
simply deal with the difference in semantics by just never requesting a
read lease in that situation.
That said, if CIFS has the same semantics as NFSv4, then why allow the
aberrant case?

Cheers,
  Trond

Re: fcntl(F GETLEASE) semantics??

[J. Bruce Fields]

On Thu, Aug 11, 2005 at 10:06:31AM -0400, Trond Myklebust wrote:
> The NFSv4 spec explicitly states that
> 
>   When a client has a read open delegation, it may not make any changes
>   to the contents or attributes of the file but it is assured that no
>   other client may do so.

I don't understand the motivation for that requirement.  As long as the
server sends write opens to the server, and doesn't try to cache them
locally, I don't see why it shouldn't be left up to the server whether
to allow writes on a read-delegated file.

> so NFSv4 cannot currently support this behaviour. If CIFS supports it,
> then maybe we have a case for going to the IETF and asking for a
> clarification to implement the same behaviour in NFSv4.

I think we could implement the correct NFSv4 delegation behaviour using
either lease semantic.

In any case, I haven't seen a real argument for reverting to the old
behaviour.  I'd rather see an established standard, or a correct
real-world application that fails, not just some arbitrary test.

--b.

Re: fcntl(F GETLEASE) semantics??

[Michael Kerrisk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1317 bytes --]

Trond,

> to den 11.08.2005 Klokka 15:22 (+0200) skreiv Michael Kerrisk:
> 
> > As noted already, I don't know much of CIFS and SAMBA.
> > But are you saying that it is sensible and consistent that
> > "a process can open a file read-write, and can't place a 
> > read lease, but can place a write lease"?  
> 
> It is just as "sensible and consistent" as being able to open the file
> read-write and being able to place a read lease but not a write lease.
> What is your point?

I think my metapoint really is this: there has never been a 
clearly documented statement of how File Leases are supposed 
to behave on Linux.  There is just some code... how is one 
supposed to know what it _should_ do?  (The manual page text 
was my attempt to discover the details, after the fact.)

Can you provide an explanation of how file leases should 
behave?  That is, a tabulation of the expected behavious 
for the possible cimbinations of

[lease type] X 
[open() access-mode employed file placing lease] X
[open() access-mode employed by other process(es)]

?

> Make no mistake: this is not a locking protocol. It is implementing
> support for a _caching_ protocol.

Yes, that I knew.

Cheers,

Michael

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Re: fcntl(F GETLEASE) semantics??

[Michael Kerrisk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 507 bytes --]

> Von: "J. Bruce Fields" <bfields@fieldses.org>

> In any case, I haven't seen a real argument for reverting to the old
> behaviour.  I'd rather see an established standard, or a correct
                                ^^^^^^^^^^^^^^^^^^^^
> real-world application that fails, not just some arbitrary test.

Agreed -- though I'd phrase it as "documented specification".

Cheers,

Michael

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 16:40 (+0200) skreiv Michael Kerrisk:
> I think my metapoint really is this: there has never been a 
> clearly documented statement of how File Leases are supposed 
> to behave on Linux.  There is just some code... how is one 
> supposed to know what it _should_ do?  (The manual page text 
> was my attempt to discover the details, after the fact.)
> 
> Can you provide an explanation of how file leases should 
> behave?  That is, a tabulation of the expected behavious 
> for the possible cimbinations of
> 
> [lease type] X 
> [open() access-mode employed file placing lease] X
> [open() access-mode employed by other process(es)]

The only document that I have is RFC3530 (the NFSv4 spec) which doesn't
really define file leases, but does define the caching protocol that
they act as support for.
In principle it is supposed to be the same protocol that CIFS uses
(although CIFS doesn't really have much in the form of documentation
that we can use to verify that fact).

To me, the NFSv4 requirements suggest:

     open()  |  lease requested    | effect on existing leases |
      flag   | F_RDLCK  | F_WRLCK  | F_RDLCK  | F_WRLCK        |
    ---------+----------+----------+---------------------------+
    O_RDONLY | okay     |  okay    |  none    |  recall        |
    O_WRONLY | EAGAIN   |  okay    |  recall  |  recall        |
    O_RDWR   | EAGAIN   |  okay    |  recall  |  recall        |

-----
 fcntl(SETLK)| effect on existing leases |
     flag    | F_RDLCK   | F_WRLCK       |
    ---------+---------------------------+
     F_RDLCK | none      | none          |
     F_WRLCK | recall    | none          |

-----
Other operation that should recall leases (both types!) are

unlink(), link(), f/l/chown(), f/chmod(), rename(), setfacl().

truncate() and utime() calls by another process.

-----
Finally, operations that should recall read leases only:

truncate() and utime() calls by your process.
-----

Cheers,
  Trond

Re: fcntl(F GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 11:06 (-0400) skreiv Trond Myklebust:

> -----
>  fcntl(SETLK)| effect on existing leases |
>      flag    | F_RDLCK   | F_WRLCK       |
>     ---------+---------------------------+
>      F_RDLCK | none      | none          |
>      F_WRLCK | recall    | none          |

Oops... That table applies to existing leases owned by your process. The
effect on leases owned by other processes is:

 fcntl(SETLK)| effect on other clients   |
     flag    | F_RDLCK   | F_WRLCK       |
    ---------+---------------------------+
     F_RDLCK | none      | recall        |
     F_WRLCK | recall    | recall        |

Cheers,
  Trond

Re: fcntl(F_GETLEASE) semantics??

[Heikki Orsila]

Peter Chubb <peterc@gelato.unsw.edu.au> wrote:
> if (fcntl(fd, F_SETLEASE, F_RDLCK) == -1)
>     fail;

Is that something inotify can do? If so, then should F_SETLEASE/GETLEASE
be deprecated for future? F_SETLEASE is Linux specific, and inotify is
generally more useful. It looks like inotify could be used to detected 
changes in any file.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: fcntl(F_GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 21:41 (+0300) skreiv Heikki Orsila:
> Peter Chubb <peterc@gelato.unsw.edu.au> wrote:
> > if (fcntl(fd, F_SETLEASE, F_RDLCK) == -1)
> >     fail;
> 
> Is that something inotify can do? If so, then should F_SETLEASE/GETLEASE
> be deprecated for future? F_SETLEASE is Linux specific, and inotify is
> generally more useful. It looks like inotify could be used to detected 
> changes in any file.

inotify does not give you synchronous notification. It just tells you
something has happened after the fact. Not the same thing at all.

Cheers,
  Trond

Re: fcntl(F_GETLEASE) semantics??

[Heikki Orsila]

On Thu, Aug 11, 2005 at 02:56:59PM -0400, Trond Myklebust wrote:
> inotify does not give you synchronous notification. It just tells you
> something has happened after the fact. Not the same thing at all.

Then what could be done for inotify to fit the purpose? SETLEASE is 
still a bad interface for userspace programs because it relies on 
signals and thus can't be conveniently put into shared libraries..

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: fcntl(F_GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 22:02 (+0300) skreiv Heikki Orsila:
> On Thu, Aug 11, 2005 at 02:56:59PM -0400, Trond Myklebust wrote:
> > inotify does not give you synchronous notification. It just tells you
> > something has happened after the fact. Not the same thing at all.
> 
> Then what could be done for inotify to fit the purpose? SETLEASE is 
> still a bad interface for userspace programs because it relies on 
> signals and thus can't be conveniently put into shared libraries..

What applications other than the very specialised case of filesystem
servers do you expect will ever want to use it?

The difference between inotify and leases is, as I said, that leases
notify the lease holder synchronously. This allows the notified process
to flush all the cached information _before_ the operation that
triggered the lease notification is executed.

Cheers,
  Trond

Re: fcntl(F_GETLEASE) semantics??

[Heikki Orsila]

On Thu, Aug 11, 2005 at 03:15:45PM -0400, Trond Myklebust wrote:
> The difference between inotify and leases is, as I said, that leases
> notify the lease holder synchronously. This allows the notified process
> to flush all the cached information _before_ the operation that
> triggered the lease notification is executed.

So you're talking about the kernel side.. I was talking about userspace 
perspective on the syscall. It would be rather odd to let a syscall
block other applications involuntarily (and thus achieving synchronous 
action in your meaning)..

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: fcntl(F_GETLEASE) semantics??

[Trond Myklebust]

to den 11.08.2005 Klokka 22:23 (+0300) skreiv Heikki Orsila:
> On Thu, Aug 11, 2005 at 03:15:45PM -0400, Trond Myklebust wrote:
> > The difference between inotify and leases is, as I said, that leases
> > notify the lease holder synchronously. This allows the notified process
> > to flush all the cached information _before_ the operation that
> > triggered the lease notification is executed.
> 
> So you're talking about the kernel side.. I was talking about userspace 
> perspective on the syscall. It would be rather odd to let a syscall
> block other applications involuntarily (and thus achieving synchronous 
> action in your meaning)..

No. What I said is true of both kernel space and userspace.

Samba needs the exact same semantics as NFSv4 has: it needs to prevent a
local open() syscall from succeeding while the CIFS clients that hold
oplocks flush their cached information (data, metadata, locks...) back
to the server.

BTW: the blockage is only temporary. If the clients don't respond within
a certain time period (as set by the global
sysctl /proc/sys/fs/lease-break-time) then the lease will be
pre-emptively broken by the kernel.

As I said, this is _very_ different from what inotify does.

Cheers,
  Trond