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

List:       amanda-hackers
Subject:    Re: dump larger than tape
From:       Geert Uytterhoeven <geert () linux-m68k ! org>
Date:       2005-09-01 13:59:01
Message-ID: Pine.LNX.4.62.0509011549580.21425 () numbat ! sonytel ! be
[Download RAW message or body]

On Thu, 1 Sep 2005, Geert Uytterhoeven wrote:
> On Wed, 31 Aug 2005, Matt Hyclak wrote:
> > On Wed, Aug 31, 2005 at 10:04:01AM +0200, Geert Uytterhoeven enlightened us:
> > > I just got this in my daily report from Amanda (2.4.5-1, Debian etch/testing):
> > > 
> > > > FAILURE AND STRANGE DUMP SUMMARY:
> > > > 
> > > > [...]
> > > > 
> > > > <host>     <dle> lev 5 FAILED [dump larger than tape, -1 KB, skipping \
> > > > incremental]
> > > > 
> > > > [...]
> > > > 
> > > > DUMP SUMMARY:
> > > > 
> > > > [...]
> > > > 
> > > > <host>     <dle>    5 FAILED \
> > > > ----------------------------------------------------
> > > > 
> > > > [...]
> > > 
> > > The funny thing is that this DLE is only about 5 GiB large (according to
> > > du), while the tapetype length is 20000 mbytes.
> 
> However, after sending the email I realized the probable cause of the problem:
> I started using server side estimates a few weeks ago, so the estimate can
> easily be larger than the actual data. And then it's larger than the tape size,
> Amanda will just refuse to back it up, right?
> 
> Anyway, it happened again last night. I just disabled server side estimates,
> and will see what happens this night.

After some suggestions from Paul Bijnens, I extracted the following relevant
information from the log:

> SETTING UP FOR ESTIMATES...
> planner: time 0.059: setting up estimates for <host>:<dle>
> <host>:<dle> overdue 12999 days for level 0
> setup_estimate: <host>:<dle>: command 0, options: none last_level 4 next_level0 \
> -12999 level_days 12    getting estimates 0 (-2) 4 (-2) -1 (-2)

> GETTING ESTIMATES...
> planner time 0.100: got result for host <host> disk <dle>: 0 -> -1K, 4 -> -1K, -1 \
> -> -2K

So the estimate from the last level 0 was -1K.
And the estimate from the last level 4 was also -1K!

> DONE QUEUE:
> 5: <host>     <dle>

> ANALYZING ESTIMATES...
> pondering <host>:<dle>... next_level0 -12999 last_level 4 (due for level 0) (no \
> estimate for level 0, picking an incr level)

> INITIAL SCHEDULE (size 544880):
> <host> <dle> pri 13000 lev 5 size -1

> DELAYING DUMPS IF NEEDED, total_size 544880, tape length 20480000 mark 1000
> planner: FAILED <host> <dle> 20050901 5 [dump larger than tape, -1 KB, skipping \
> incremental]

And the total estimate is -1K, which is wrong.

Some investigation of older reports showed two strange things happened:
 1. The last level 0 was already overwritten[*], hence Amanda didn't have an
    estimate for a level 0 dump, causing the first -1.
 2. The previous dump was a level 4, but it didn't happen because the disk
    holding my vtapes had filled up. Hence Amanda didn't have an estimate for
    that dump neither, causing another -1.

([*] I didn't mind, since I had a copy of older vtapes on an external disk)

It looks like if Amanda has historical data about the DLE, but nothing usable,
the estimate is -1K, which is converted to unsigned and becomes larger than the
tape length. Hence Amanda refuses to dump the DLE.

Probably she should use the same estimate as for a new DLE?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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