Date: Wed, 15 May 2002 01:35:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <bright@mu.org> Cc: Richard Sharpe <rsharpe@ns.aus.com>, freebsd-hackers@freebsd.org Subject: Re: File locking, closes and performance in a distributed filesystemenv Message-ID: <3CE21DE4.441F6B36@mindspring.com> References: <Pine.LNX.4.33.0205151117270.5078-100000@ns.aus.com> <3CE1F8E2.868B2965@mindspring.com> <20020515062425.GD1585@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > As Terry stated you can't do that, however you could cache that the > VNODE has a lock, that would reduce the requirement for calling the > ADVLOCK VOP. You'd really have to know when the lock list went to NULL, to get any benefit out of it, since locking would still end up being per-file sticky. You could post-check after every successful unlock... but to cache the remote state would mean another RPC to ask for locks, which would just be front-loading the expense, instead of back-loading it. I don't think this would be a win: applications don't really choose selective locking: either they tend to lock everything or they don't respect locking at all. Also, it's very common to check a lock before doing something, so you'll still have all that unnecessary traffic. You really need to cache the entire local lock list. The most reasonable way to so this would be for a "magic" return value from the lock primitive. But since you can't get cooperation from the other end on that, the only reasonable way is to maintain the lock list locally as well as remotely, and then do a check for NULL (instead of the flag) before attempting to proxy the unnecessary unlock request. Which is basically what I said the first time. 8-). I suspect there are other things he's not telling us, too, like session handoff or other clustering protocols, which means that you could have your locks handed off, and end up without the "there's a lock" flag set, in any case, so there's still room to shoot your foot off. This may be an incorrect suspicion, but... generally, distributed file systems are built that way for a particular reason/application set, which includes things like client virtualization/migration/handoff. Too fun. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CE21DE4.441F6B36>