On Sun Jul 29 2007 at 23:48:36 +0100, Andrew Doran wrote:
> On Sun, Jul 29, 2007 at 08:42:12PM +0300, Antti Kantee wrote:
> 
> > You are fixing a different problem.  It should be fixed independently of
> > this issue.  They just happened to be intertwined.  But that can happen
> > $whenever - at least I'm not aware of any more problems with the current
> > rele-then-lock weirdosity.
> 
> Ok, maybe we are. I'll have to read back but problem I'm describing is
> certainly there.

I'm not saying it isn't there.

But, I am now wondering why no one seems to be hitting it?  vnodes are
rarely freed and we continue to use dangling references which work
by luck?

> > > o We'd need a VOP_RWLOCK or VOP_RANGELOCK for concurrent reads/writes.
> > 
> > Is a rangelock really helpful?
> 
> I was thinking of databases. Since it would be file system internal, there's
> no reason we couldn't start out with the file system ignoring any supplied
> ranges and locking the inode outright as is done now. Do you see something
> else?

No.  I'm just wondering if it can create any funnyness and if you have
a case where it provides a clear benefit.  It does sound like something
possibly with too many degrees of freedom.  But if you're allowed to
hold either a full lock or one rangelock, it shouldn't be too confusing
for anyone.  Hmm... we probably need some kind of state in the request
then, as a rangelocked operation will probably need the inode lock for
a short while.  Or recursive locks.

Well, anyway, not opposed.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"