Bacula-users

Re: [Bacula-users] [Bacula-devel] 2.4.1 not releasing tapes

2008-08-30 14:41:11
Subject: Re: [Bacula-users] [Bacula-devel] 2.4.1 not releasing tapes
From: Kern Sibbald <kern AT sibbald DOT com>
To: bacula-devel AT lists.sourceforge DOT net
Date: Sat, 30 Aug 2008 20:39:39 +0200
Hello,

OK, assuming that the old output is from 2.4.1 and the new from 2.4.2:

On Saturday 30 August 2008 17:19:44 Shad L. Lords wrote:
> Shad L. Lords wrote:
> > Here is the relevant part of status storage from bconsole:
> >
> > Device status:
> > Autochanger "SL-10K" with devices:
> >     "SL-10K-Drive1" (/dev/nst0)
> >     "SL-10K-Drive2" (/dev/nst1)
> > Device "SL-10K-Drive1" (/dev/nst0) is not open.
> >      Drive 0 is not loaded.
> > Device "SL-10K-Drive2" (/dev/nst1) is not open.
> >      Drive 1 is not loaded.
> > ====
> >
> > In Use Volume status:
> > MA3004 on device "SL-10K-Drive2" (/dev/nst1)
> >      Reader=0 writers=0 devres=0 volinuse=0
> > WA3003 on device "SL-10K-Drive2" (/dev/nst1)
> >      Reader=0 writers=0 devres=0 volinuse=0

It isn't clear what the issue is.  The above In Use Volume status could mean 
that one of those two volumes was in the drive and the other one is wanted.  
This is not so unusual, even though it may not be obvious at first sight.

>
> It appears this issue still exists in 2.4.2.  I've just run into a
> situation similar.  Before it just used to mark the tape as in use but
> the backup would complete.  This time however it blocked the backup.
> Here is the output I've currently got:
>
> Device status:
> Autochanger "Scalar-100" with devices:
>     "Scalar-100-Drive1" (/dev/nst0)
>     "Scalar-100-Drive2" (/dev/nst1)
>     "Scalar-100-Drive3" (/dev/nst2)
>     "Scalar-100-Drive4" (/dev/nst3)
> Device "Scalar-100-Drive1" (/dev/nst0) is mounted with:
>      Volume:      DA2019
>      Pool:        Daily
>      Media type:  AIT-2
>      Slot 59 is loaded in drive 0.
>      Total Bytes=22,594,424,832 Blocks=350,235 Bytes/block=64,512
>      Positioned at File=24 Block=0
> Device "Scalar-100-Drive2" (/dev/nst1) is not open.
>      Drive 1 is not loaded.
> Device "Scalar-100-Drive3" (/dev/nst2) is mounted with:
>      Volume:      DA3007
>      Pool:        Daily
>      Media type:  AIT-3
>      Device is BLOCKED waiting for mount of volume "DA3007",
>         Pool:        Daily
>         Media type:  AIT-3
>      Slot 8 is loaded in drive 2.
>      Total Bytes Read=0 Blocks Read=0 Bytes/block=0
>      Positioned at File=0 Block=0
> Device "Scalar-100-Drive4" (/dev/nst3) is not open.
>      Device is BLOCKED waiting for mount of volume "DA3008",
>         Pool:        Daily
>         Media type:  AIT-3
>      Drive 3 status unknown.
> ====
>
> Used Volume status:
> DA2019 on device "Scalar-100-Drive1" (/dev/nst0)
>      Reader=0 writers=0 devres=0 volinuse=0
> DA3007 on device "Scalar-100-Drive4" (/dev/nst3)
>      Reader=0 writers=0 devres=1 volinuse=1
> DA3008 on device "Scalar-100-Drive4" (/dev/nst3)
>      Reader=0 writers=0 devres=1 volinuse=1
> ====

I don't see how this compares to the above since here it clearly says that it 
is blocked waiting for a mount.  You might try mounting that drive via 
bconsole and see what happens.  Otherwise, there is not much to go on because 
I don't have the job output and cannot tell why it is blocked. 

>
> The interesting thing is that DA3008 is in slot 8.  Drive3 (nst2) says
> DA3007 is in the drive but it is blocking waiting for that same tape.
> It also mentions that slot 8 is loaded but that is wrong.  Slot 7 is
> loaded.  I've visually verified that DA3007 is in drive 3.  I'm still
> trying to get a debugging log for you.
>

The Bacula SD has so many features that there are a number of ways to drive it 
into deadlock situations -- including problems with the autochanger script 
not working.  Probably the most important output is the job output.  If the 
job is blocked and you cannot unblock it, you can cancel it, then possibly do 
a bconsole mount, and that should terminate the job so that you can see what 
went wrong.  If the job output doesn't show enough information, then looking 
through a -d150 debug listing can probably help -- the problem is that it 
takes a long time to examine such output.

Regards,

Kern

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>