[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WAPBL patch for testing
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?
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
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig
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...
Main Index |
Thread Index |