Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: WAPBL patch for testing



On Fri, Oct 31, 2008 at 03:10:24PM -0400, Thor Lancelot Simon wrote:
> On Fri, Oct 31, 2008 at 08:03:32PM +0100, Juergen Hannken-Illjes wrote:
> > On Fri, Oct 31, 2008 at 07:03:59PM +0100, Joerg Sonnenberger wrote:
> > > Hi all,
> > > the attached patch is supposed to fix both hangs (wchan tstile) and
> > > performance issues with WAPBL. Please test it and report any issues.
> > > I'd like to see some review for this too. I can't find a reason why the
> > > WAPBL lock should be hold in that places nor can I find a code path from
> > > UFS itself to getpages with lock already being hold, but I could be
> > > wrong.
> > > 
> > > Joerg
> > 
> > The reason for these wapbl locks is ffs snapshots.  VOP_PUTPAGES() may
> > need to copy-on-write which needs to run inside a wapbl transaction
> > as we allocate blocks here.
> 
> Would this problem be any easier to solve if the snapshot and wapbl
> code used the same notion of a "transaction"?  I was very surprised
> to see that wapbl brought in an a whole new idea of a "fs transaction"
> when the snapshot code already seemed to have one.

While wapbl takes exclusive locks on possible meta data write fstrans
gates file system activity (read and write).  We could try to merge
them with fine grained fstrans (for read, for write, ...).

To me wapbl using a lock is wrong in the first place.  It would be better
to collect wapbl data per thread or per inode and have a kernel thread
collect and flush complete wapbl transactions.

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


Home | Main Index | Thread Index | Old Index