[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amanda-hackers
Subject:    Re: Another taper bites the dust ...
From:       "Dustin J. Mitchell" <dustin () zmanda ! com>
Date:       2009-10-31 1:15:11
Message-ID: 42338fbf0910301815h5987a127w2e58b458b3e9ef2c () mail ! gmail ! com
[Download RAW message or body]

On Fri, Oct 30, 2009 at 2:59 PM, Dustin J. Mitchell <dustin@zmanda.com> wrote:
> I'm trying to figure out if the slab size of 0 that it prints is real
> (which would be *very* strange, since just a few lines earlier it gave
> a correct slab size of 327680) or a figment of the printf conversion.
> Can you apply this patch:

Actually, I found the bug.  Well, two bugs.

1. The slab_size of 0 was real, and occurred because data started
flowing before the XferDestTaperSplitter got its first device, and
thus before it could use the block size to select a slab_size.  A
recent change in trunk enables the object to get a device much earlier
in the setup process, which fixes this problem.

2. When the allocation failed, the XferDestTaperSplitter cancelled the
transfer, then waited for the cancellation to complete, but did so
while holding a lock.  Simply moving the wait-for-completion after the
unlocking of the mutex fixes this deadlock.

Fixes are in the most recent two commits here:

http://github.com/djmitche/amanda/commits/taper-fixes-2

I'm a bit embarassed at these bugs, but on the other hand they are
good bugs to have -- not evidence of a bad design (in fact, this
design has proven quite adaptable to the new DirectTCP and NDMP
work!), just of missed finishing touches.

By the way, you'll need to apply those two patches to a fairly recent
checkout of Amanda -- they depend on changes made on 10/21.

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com
[prev in list] [next in list] [prev in thread] [next in thread]