Subject: Re: CVS commit: src/sys
To: None <tech-kern@NetBSD.org>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: tech-kern
Date: 07/30/2007 15:10:42
On Dec 20, 10:49am, Antti Kantee wrote:
} 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:
} 
} > > > 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.

     While we're discussing locks, how about Samba style oplocks?
Filesystem code isn't my area, so I have no idea what it would take to
implement them.

}-- End of excerpt from Antti Kantee