On Mon, Jun 26, 2006 at 02:31:44PM -0700, Bill Studenmund wrote:
> On Mon, Jun 26, 2006 at 08:30:20PM +0200, Juergen Hannken-Illjes wrote:
> > On Mon, Jun 26, 2006 at 09:43:59AM -0700, Bill Studenmund wrote:
> > > On Sat, Jun 24, 2006 at 11:05:04AM +0200, Juergen Hannken-Illjes wrote:
> > > > On Fri, Jun 23, 2006 at 05:14:00PM -0700, Bill Studenmund wrote:
> > > > > 
> > > > > Especially if we go with the idea of having the file system grab and 
> > > > > release the mountpoint-transaction-lock (the current incarnation of the 
> > > > > "gate" you spoke of originally, the thing that makes us atomic w.r.t. a 
> > > > > snapshot), then it's not a problem. We just have the read and write code 
> > > > > in fifofs not take the transaction lock, and we're fine.
> > > 
> > > I'm sorry, but this is an important point. I have the feeling it was 
> > > missed.
> > 
> > Not sure I get it right: you mean taking the transaction lock for
> > read/write/ioctl in every file system while taking it for other operations
> > outside?
> > 
> > Looks difficult to maintain.
> 
> How is it difficult to maintain?
> 
> The idea is that we only use transaction locks above the file system if we
> have a real transaction.

Implementing the transaction locks this way leads to this situation:

A file system gets quiet.  Now we are sure all its operations are either
complete or have not started yet.  But we have locks held.  Our next
step is to sync the current file system state to disk.  None of the
operations we have (VFS_SYNC and friends) is usable because they will
deadlock.  So we have to add another VFS operation to sync to disk
ignoring locks.  Looks ugly and hard to maintain.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)