Hey all-
I've got a dillema and I'm not sure how to anwser it. I recently had
someone mention to me that some of the operations executed via fcntl
(specifically F_SETLEASE was demonstrated to me) don't check the file attributes
on the server before executing their operations. This can lead to erroneous
behavior in which, if someone updates file permissions or ownership from another
node mounting an NFS share, a node attempting to do something like a F_SETLEASE
operation will fail when it should succede, or vice versa.
I can see who this could be interpreted as a bug, but I can also see how
we might not want to change the behavior, given that the fcntl code currently
does not call down to the underlying filesystem for most operations (as it
doesn't nominally need to), and the problem can easily be avoided by the use of
a file lock and a stat operation. Is there consensus on this issue, as to how
it should operate, or how we would like it to operate?
Thanks & Regards
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Neil Horman wrote:
>Hey all-
> I've got a dillema and I'm not sure how to anwser it. I recently had
>someone mention to me that some of the operations executed via fcntl
>(specifically F_SETLEASE was demonstrated to me) don't check the file attributes
>on the server before executing their operations. This can lead to erroneous
>behavior in which, if someone updates file permissions or ownership from another
>node mounting an NFS share, a node attempting to do something like a F_SETLEASE
>operation will fail when it should succede, or vice versa.
>
> I can see who this could be interpreted as a bug, but I can also see how
>we might not want to change the behavior, given that the fcntl code currently
>does not call down to the underlying filesystem for most operations (as it
>doesn't nominally need to), and the problem can easily be avoided by the use of
>a file lock and a stat operation. Is there consensus on this issue, as to how
>it should operate, or how we would like it to operate?
>
It seems to me that all operations, which use attributes, in any fashion,
whether to make decisions or to return them to the user level, should
verify that the attributes are up to date before using them. This
verification
may mean talking to the server or simply deciding that the attributes are
up to date because they are still within the attribute cache timeout period.
The "noac" option should mean, perhaps among other things, that the
attribute
cache timeout period is zero in length.
If the fcntl code doesn't call into the file system to do the actual
operations, then it needs to verify that the attributes that it is using
are up to date. If it doesn't, then it is broken and needs to be modified
to do so.
Thanx...
ps
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Feb 23, 2006 at 08:36:09AM -0500, Peter Staubach wrote:
> Neil Horman wrote:
>
> >Hey all-
> > I've got a dillema and I'm not sure how to anwser it. I recently had
> >someone mention to me that some of the operations executed via fcntl
> >(specifically F_SETLEASE was demonstrated to me) don't check the file
> >attributes
> >on the server before executing their operations. This can lead to
> >erroneous
> >behavior in which, if someone updates file permissions or ownership from
> >another
> >node mounting an NFS share, a node attempting to do something like a
> >F_SETLEASE
> >operation will fail when it should succede, or vice versa.
> >
> > I can see who this could be interpreted as a bug, but I can also see
> > how
> >we might not want to change the behavior, given that the fcntl code
> >currently
> >does not call down to the underlying filesystem for most operations (as it
> >doesn't nominally need to), and the problem can easily be avoided by the
> >use of
> >a file lock and a stat operation. Is there consensus on this issue, as to
> >how
> >it should operate, or how we would like it to operate?
> >
>
> It seems to me that all operations, which use attributes, in any fashion,
> whether to make decisions or to return them to the user level, should
> verify that the attributes are up to date before using them. This
> verification
> may mean talking to the server or simply deciding that the attributes are
> up to date because they are still within the attribute cache timeout period.
> The "noac" option should mean, perhaps among other things, that the
> attribute
> cache timeout period is zero in length.
>
> If the fcntl code doesn't call into the file system to do the actual
> operations, then it needs to verify that the attributes that it is using
> are up to date. If it doesn't, then it is broken and needs to be modified
> to do so.
>
> Thanx...
>
> ps
Thank you Peter, I tend to agree with you, but I wanted to be sure. It's just
been my experience that others people may make the agrument that if you truly
want to guarantee that truly have the latest attributes on a file in a race free
fashion then you need to serialize access to that file (get a lock, access the
file, unlock). Since noac doesn't provide that serialization, the argument can
be made that its a best effort option, and in some events its "ok" to avoid the
extra check.
Since I agree with your stand though, I'll write the patch :).
Thanks & Regards
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2006-02-23 at 07:42 -0500, Neil Horman wrote:
> Hey all-
> I've got a dillema and I'm not sure how to anwser it. I recently had
> someone mention to me that some of the operations executed via fcntl
> (specifically F_SETLEASE was demonstrated to me) don't check the file attributes
> on the server before executing their operations. This can lead to erroneous
> behavior in which, if someone updates file permissions or ownership from another
> node mounting an NFS share, a node attempting to do something like a F_SETLEASE
> operation will fail when it should succede, or vice versa.
Who is trying to use F_SETLEASE on an NFS share in these conditions?
That is unbelievably borken: leases are supposed to guarantee that
nobody is changing the file. If the file is being changed on the server,
then exactly what use do they serve?
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Feb 23, 2006 at 11:12:13AM -0500, Trond Myklebust wrote:
> On Thu, 2006-02-23 at 07:42 -0500, Neil Horman wrote:
> > Hey all-
> > I've got a dillema and I'm not sure how to anwser it. I recently had
> > someone mention to me that some of the operations executed via fcntl
> > (specifically F_SETLEASE was demonstrated to me) don't check the file attributes
> > on the server before executing their operations. This can lead to erroneous
> > behavior in which, if someone updates file permissions or ownership from another
> > node mounting an NFS share, a node attempting to do something like a F_SETLEASE
> > operation will fail when it should succede, or vice versa.
>
> Who is trying to use F_SETLEASE on an NFS share in these conditions?
>
> That is unbelievably borken: leases are supposed to guarantee that
> nobody is changing the file. If the file is being changed on the server,
> then exactly what use do they serve?
>
> Cheers,
> Trond
>
The exact case that was reported to me is as follows:
1) Client A runs a process with a uid of X that opens a file on an NFS share.
The opened file has a uid of Y. The share is mounted with the noac option
2) Client B chmods the same file on the same share so thats its owning uid is X.
3) Client A attempts to issue a fcntl(F_SETLEASE operation on the open file
descriptor.
4) Client A has -EACCESS returned from the fcntl call.
Now, clearly, this is not the safest thing in the world to do, and the safe/race
free way to do this would be to set a file lock and stat the file before issuing
the setlease command. But I can also see how, after reading the man page for
nfs and fcntl, one would expect this to just work if they mounted the share with
noac, under the presumption that we check the file attributes on the server
every time the client needs to check them for any purpose. And since we don't
do that in the case of an F_SETLEASE operation, I can see how some might think
it broken. In fact I tend to think of it as somewhat broken, but I know thats
may not be a shared view, so I was looking for input as to weather or not it was
worth fixing, and if not, why not. If you have a good argument for why its
currently working as designed, I'll happily defer to that judgement.
Thanks & Regards
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2006-02-23 at 14:22 -0500, Neil Horman wrote:
> On Thu, Feb 23, 2006 at 11:12:13AM -0500, Trond Myklebust wrote:
> > On Thu, 2006-02-23 at 07:42 -0500, Neil Horman wrote:
> > > Hey all-
> > > I've got a dillema and I'm not sure how to anwser it. I recently had
> > > someone mention to me that some of the operations executed via fcntl
> > > (specifically F_SETLEASE was demonstrated to me) don't check the file attributes
> > > on the server before executing their operations. This can lead to erroneous
> > > behavior in which, if someone updates file permissions or ownership from another
> > > node mounting an NFS share, a node attempting to do something like a F_SETLEASE
> > > operation will fail when it should succede, or vice versa.
> >
> > Who is trying to use F_SETLEASE on an NFS share in these conditions?
> >
> > That is unbelievably borken: leases are supposed to guarantee that
> > nobody is changing the file. If the file is being changed on the server,
> > then exactly what use do they serve?
> >
> > Cheers,
> > Trond
> >
>
> The exact case that was reported to me is as follows:
>
> 1) Client A runs a process with a uid of X that opens a file on an NFS share.
> The opened file has a uid of Y. The share is mounted with the noac option
>
> 2) Client B chmods the same file on the same share so thats its owning uid is X.
>
> 3) Client A attempts to issue a fcntl(F_SETLEASE operation on the open file
> descriptor.
>
> 4) Client A has -EACCESS returned from the fcntl call.
>
> Now, clearly, this is not the safest thing in the world to do, and the safe/race
> free way to do this would be to set a file lock and stat the file before issuing
> the setlease command. But I can also see how, after reading the man page for
> nfs and fcntl, one would expect this to just work if they mounted the share with
> noac, under the presumption that we check the file attributes on the server
> every time the client needs to check them for any purpose. And since we don't
> do that in the case of an F_SETLEASE operation, I can see how some might think
> it broken. In fact I tend to think of it as somewhat broken, but I know thats
> may not be a shared view, so I was looking for input as to weather or not it was
> worth fixing, and if not, why not. If you have a good argument for why its
> currently working as designed, I'll happily defer to that judgement.
It is not worth fixing. There is currently no support for using
fcntl(F_SETLEASE) in an NFS shared environment, and there are no plans
to support it unless at some point we get NFS protocol support for it.
Leases will currently work as expected in an NFS environment where a
single client has exclusive access to the file (and hence where local
locking works), but that is all.
In the scenario you describe, we would need NFS protocol support in
order to get leases to work at all. This is due to the fact that under
the lease model, the process holding the lease expects to be notified
_synchronously_ of any conflicting open() calls, renames, mode changes,
truncate calls, etc to the file. By "synchronously", I mean that the
notification must come _before_ the server actually performs the change.
The EACCESS race that you describe should be the very least of your
worries.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
>
>It is not worth fixing. There is currently no support for using
>fcntl(F_SETLEASE) in an NFS shared environment, and there are no plans
>to support it unless at some point we get NFS protocol support for it.
>
>Leases will currently work as expected in an NFS environment where a
>single client has exclusive access to the file (and hence where local
>locking works), but that is all.
>
>In the scenario you describe, we would need NFS protocol support in
>order to get leases to work at all. This is due to the fact that under
>the lease model, the process holding the lease expects to be notified
>_synchronously_ of any conflicting open() calls, renames, mode changes,
>truncate calls, etc to the file. By "synchronously", I mean that the
>notification must come _before_ the server actually performs the change.
>
>The EACCESS race that you describe should be the very least of your
>worries.
>
I would disagree somewhat. There is a customer who has stumbled into this
situation. We know that there is a bug here, that it has affected at one
customer, and the risk for fixing it is very small. The gains might not be
obvious, but it would make at one customer even slightly happier. That's
worth the small amount of effort that it would take to fix this.
Thanx...
ps
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2006-02-23 at 14:50 -0500, Peter Staubach wrote:
> Trond Myklebust wrote:
>
> >
> >It is not worth fixing. There is currently no support for using
> >fcntl(F_SETLEASE) in an NFS shared environment, and there are no plans
> >to support it unless at some point we get NFS protocol support for it.
> >
> >Leases will currently work as expected in an NFS environment where a
> >single client has exclusive access to the file (and hence where local
> >locking works), but that is all.
> >
> >In the scenario you describe, we would need NFS protocol support in
> >order to get leases to work at all. This is due to the fact that under
> >the lease model, the process holding the lease expects to be notified
> >_synchronously_ of any conflicting open() calls, renames, mode changes,
> >truncate calls, etc to the file. By "synchronously", I mean that the
> >notification must come _before_ the server actually performs the change.
> >
> >The EACCESS race that you describe should be the very least of your
> >worries.
> >
>
> I would disagree somewhat. There is a customer who has stumbled into this
> situation. We know that there is a bug here, that it has affected at one
> customer, and the risk for fixing it is very small. The gains might not be
> obvious, but it would make at one customer even slightly happier. That's
> worth the small amount of effort that it would take to fix this.
Will the customer be happy to find out that the application breaks in
much more nefarious ways as a result of a non-working lease?
If this is Samba, then the correct answer is obvious: turn off oplocks
in the configuration file since they won't ever work as expected anyway.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
>>I would disagree somewhat. There is a customer who has stumbled into this
>>situation. We know that there is a bug here, that it has affected at one
>>customer, and the risk for fixing it is very small. The gains might not be
>>obvious, but it would make at one customer even slightly happier. That's
>>worth the small amount of effort that it would take to fix this.
>>
>>
>
>Will the customer be happy to find out that the application breaks in
>much more nefarious ways as a result of a non-working lease?
>
>If this is Samba, then the correct answer is obvious: turn off oplocks
>in the configuration file since they won't ever work as expected anyway.
>
Well, it may or may not break, actually. I would think that it would depend
upon what assumptions were being made by the application.
I would still suggest that the cost of fixing something which is clearly
broken is outweighed by the benefit of making a customer, at least
temporarily,
happy. If that customer is porting something from a system does support
F_SETLEASE, such as Solaris, and was happy with the way that it worked
there,
then they may be happy with the current support of F_SETLEASE in Linux.
It is even possible that they were using leases for some reason instead of
file/record locking. Who knows? :-)
Thanx...
ps
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2006-02-23 at 15:50 -0500, Peter Staubach wrote:
> >Will the customer be happy to find out that the application breaks in
> >much more nefarious ways as a result of a non-working lease?
> >
<snip>
> Well, it may or may not break, actually. I would think that it would depend
> upon what assumptions were being made by the application.
>
> I would still suggest that the cost of fixing something which is clearly
> broken is outweighed by the benefit of making a customer, at least
> temporarily,
> happy. If that customer is porting something from a system does support
> F_SETLEASE, such as Solaris, and was happy with the way that it worked
> there,
> then they may be happy with the current support of F_SETLEASE in Linux.
>
> It is even possible that they were using leases for some reason instead of
> file/record locking. Who knows? :-)
Precisely. In which case we should be helping them to figure out how to
correctly set up their system in such a way that the F_SETLEASE spec
does apply. Helping them to shoot themselves in the foot by papering
over what is basically a symptom that _demonstrates_ they are
misapplying it is not, in my book, good customer relations.
The bottom line is that F_SETLEASE does not work in a multi-client
environment where more than one NFS client at a time is accessing the
file.
BTW: I seriously doubt F_SETLEASE on Solaris is in any better shape.
Unless they are using some secret 3rd party protocol to ensure that
coherency across the NFS clients, they are in exactly the same situation
the we are.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Feb 23, 2006 at 05:31:21PM -0500, Trond Myklebust wrote:
> On Thu, 2006-02-23 at 15:50 -0500, Peter Staubach wrote:
>
> > >Will the customer be happy to find out that the application breaks in
> > >much more nefarious ways as a result of a non-working lease?
> > >
> <snip>
> > Well, it may or may not break, actually. I would think that it would depend
> > upon what assumptions were being made by the application.
> >
> > I would still suggest that the cost of fixing something which is clearly
> > broken is outweighed by the benefit of making a customer, at least
> > temporarily,
> > happy. If that customer is porting something from a system does support
> > F_SETLEASE, such as Solaris, and was happy with the way that it worked
> > there,
> > then they may be happy with the current support of F_SETLEASE in Linux.
> >
> > It is even possible that they were using leases for some reason instead of
> > file/record locking. Who knows? :-)
>
> Precisely. In which case we should be helping them to figure out how to
> correctly set up their system in such a way that the F_SETLEASE spec
> does apply. Helping them to shoot themselves in the foot by papering
> over what is basically a symptom that _demonstrates_ they are
> misapplying it is not, in my book, good customer relations.
>
> The bottom line is that F_SETLEASE does not work in a multi-client
> environment where more than one NFS client at a time is accessing the
> file.
> BTW: I seriously doubt F_SETLEASE on Solaris is in any better shape.
> Unless they are using some secret 3rd party protocol to ensure that
> coherency across the NFS clients, they are in exactly the same situation
> the we are.
>
> Cheers,
> Trond
>
Trond, you make a good point here, after re-reading the man page for F_SETLEASE,
I agree, this operation just isn't going to work over NFS, at least not without
significant additional work. From that standpoint we shouldn't worry about this
too much.
That being said however, the error we are discussing isn't in any way an
indicator of the brokeness which you describe above. If, in the problem
description that I gave in my last post, the file uid had matched the process
uid on client NODE A, the fcntl operation would have succeded without a problem,
and would have happily failed to preform its function as defined in the man
page, and would have done so silently.
This strikes in a somewhat simmilar fashion to the flock() function. For years
it just didn't work over NFS (and still IIRC doesn't), but a while ago we put in
a check so that it returned an appropriate error in the event that you tried to
flock a file over NFS. Perhaps what we need to do here is:
1) Fix the noac problem as previously described
2) Add a check (simmilar to that of flock) such that attempting to set a lease
on a file over NFS results in a return of -ENOTSUPP or another appropriate
error.
Then when/if we decide to push for protocol support for F_SETLEASE over NFS we
can remove the check, and we don't need to revisit the attribute cache issue,
which (and I don't currently have the resources to check on this), but I think also
affects other multi-accessor file systems (CIFS, OCFS, FreeVXFS, GFS, etc)..
Thoughts?
Thanks & Regards
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 2006-02-24 at 09:06 -0500, Neil Horman wrote:
> This strikes in a somewhat simmilar fashion to the flock() function. For years
> it just didn't work over NFS (and still IIRC doesn't), but a while ago we put in
> a check so that it returned an appropriate error in the event that you tried to
> flock a file over NFS. Perhaps what we need to do here is:
Flock should now work over NFS. Try it.
> 1) Fix the noac problem as previously described
> 2) Add a check (simmilar to that of flock) such that attempting to set a lease
> on a file over NFS results in a return of -ENOTSUPP or another appropriate
> error.
Why waste time doing (1) at all, since a "noac" mount usually means you
are in a situation where (2) applies?
How about instead we do
(3) Fix the fcntl (2) manpage so that it mentions distributed
filesystems and the caveats of using F_SETLEASE on them.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Feb 24, 2006 at 09:26:55AM -0500, Trond Myklebust wrote:
> On Fri, 2006-02-24 at 09:06 -0500, Neil Horman wrote:
>
> > This strikes in a somewhat simmilar fashion to the flock() function. For years
> > it just didn't work over NFS (and still IIRC doesn't), but a while ago we put in
> > a check so that it returned an appropriate error in the event that you tried to
> > flock a file over NFS. Perhaps what we need to do here is:
>
> Flock should now work over NFS. Try it.
>
Sorry, missed the reversal of sense in the check for FL_FLOCK in nfs_flock. But
the precedent still remains that we can check to deny access to a particular
service dependent on the underlying filesystem.
> > 1) Fix the noac problem as previously described
> > 2) Add a check (simmilar to that of flock) such that attempting to set a lease
> > on a file over NFS results in a return of -ENOTSUPP or another appropriate
> > error.
>
> Why waste time doing (1) at all, since a "noac" mount usually means you
> are in a situation where (2) applies?
>
If this problem only exists on NFS, then I'd tend to agree. Although again, it
would seem that other multi-access file systems are going to suffer from the
same drawback since we never call to the underlying filesystem to get the latest
attributes. two nodes could access a file in OCFS or GFS in the same way, and I
would expect the same problem would occur. Do you agree?
> How about instead we do
>
> (3) Fix the fcntl (2) manpage so that it mentions distributed
> filesystems and the caveats of using F_SETLEASE on them.
>
Agreed, this would probably be a good idea regardless.
Regards
Neil
> Cheers,
> Trond
>
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 2006-02-24 at 10:25 -0500, Neil Horman wrote:
> > > 1) Fix the noac problem as previously described
> > > 2) Add a check (simmilar to that of flock) such that attempting to set a lease
> > > on a file over NFS results in a return of -ENOTSUPP or another appropriate
> > > error.
> >
> > Why waste time doing (1) at all, since a "noac" mount usually means you
> > are in a situation where (2) applies?
> >
> If this problem only exists on NFS, then I'd tend to agree. Although again, it
> would seem that other multi-access file systems are going to suffer from the
> same drawback since we never call to the underlying filesystem to get the latest
> attributes. two nodes could access a file in OCFS or GFS in the same way, and I
> would expect the same problem would occur. Do you agree?
...and I would say if so, then the exact same argument applies: you are
in a situation where the whole lease concept is broken.
Leases are _not_ the same as locks: they are not designed for
synchronisation purposes, but rather as a cache consistency device. In
all the situations you have described so far there is no possibility for
maintaining even local cache consistency.
As for returning ENOTSUPP, I'm sceptical to that too: that is a radical
change in user behaviour that can also affect systems where the lease
use _is_ valid (i.e. the single client case).
The time to fix all this is when at least one of the above filesystems
develops protocol support for leases and finds that it needs a lease
callback, not before.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs