Re: WAPBL patch for testing

[Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>]

On Mon, Nov 03, 2008 at 02:32:30AM +0100, Joerg Sonnenberger wrote:
> On Sun, Nov 02, 2008 at 09:55:06PM +0100, Juergen Hannken-Illjes wrote:
> > I don't know, what you intend to change -- we NEED the wapbl lock for
> > GOP_WRITE() as it was before, when there was a ffs_gop_write() that did
> > the same that genfs_putpages() does now.
> 
> I still don't think this is needed. Looking at your trace at least one
> obvious question comes up. Why is ffs_write holding the WAPBL lock all
> the time through the transaction? Isn't it enough to hold it over each
> balloc_range call and do the actual ubc_uiomove without?
> 
> Joerg

1). When it comes to copy-on-write ffs_copyonwrite() needs to allocate
    a block. Therefore it has to start a wapbl transaction.
    But how could we know if we are already inside a transaction?
    We could add a flag to fscow_run() noting the current wapbl
    transaction state if all non-meta-data were written outside
    a transaction and here comes ...

2). VOP_WRITE() is sometimes called inside a wapbl transaction and most
    time outside.  At least ufs_symlink() calls it inside a transaction.
    You should ask simonb and oster for more details.
    So here is the start of the problem.  Non-meta-data written inside
    a transaction.  As there is no chance to tag non-meta-data writes
    with the current wapbl transaction state we had to make sure all
    data gets written inside a transaction.

Short version:  If you are able to kill IO_JOURNALLOCKED it should
be possible to also kill PGO_JOURNALLOCKED and the wapbl transaction
in VOP_PUTPAGES().

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

Btw.: I still think wapbl should work without exclusive locks by making
      the transaction per-lwp or per-inode and have a kernel thread consume
      and handle them...