Bacula-users

Re: [Bacula-users] Bacula-users Digest, Vol 42, Issue 10

2009-10-11 17:11:48
Subject: Re: [Bacula-users] Bacula-users Digest, Vol 42, Issue 10
From: "Ulrich Schaefer" <huschaefer AT gmx DOT net>
To: bacula-users AT lists.sourceforge DOT net
Date: Sun, 11 Oct 2009 23:07:03 +0200
please stop sending these messages. my husband died.



-------- Original-Nachricht --------
> Datum: Sun, 11 Oct 2009 17:15:01 +0000
> Von: bacula-users-request AT lists.sourceforge DOT net
> An: bacula-users AT lists.sourceforge DOT net
> Betreff: Bacula-users Digest, Vol 42, Issue 10

> Send Bacula-users mailing list submissions to
>       bacula-users AT lists.sourceforge DOT net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.sourceforge.net/lists/listinfo/bacula-users
> or, via email, send a message with subject or body 'help' to
>       bacula-users-request AT lists.sourceforge DOT net
> 
> You can reach the person managing the list at
>       bacula-users-owner AT lists.sourceforge DOT net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bacula-users digest..."
> 
> 
> Today's Topics:
> 
>    1. No longer working with nunet (florian.schuerfeld AT nunet DOT de)
>    2. Re: [Bacula-devel] Minor feature request (just  something that
>       would be handy, pretty low priority) (Kern Sibbald)
>    3. "ClientRunBeforeJob" - spaces in pathnames on   Windows.
>       ARGH...Help? (Sean M Clark)
>    4. Re: [Bacula-devel] [FEATURE REQUEST] convert two full backups
>       to one full and one     reverse incremental (or decremental?)
>       (Kern Sibbald)
>    5. Re: "ClientRunBeforeJob" - spaces in pathnames  on      Windows.
>       ARGH...Help? (Markus Falb)
>    6. Re: "ClientRunBeforeJob" - spaces in pathnames on Windows.
>       ARGH...Help? (ebollengier)
>    7. Re: "ClientRunBeforeJob" - spaces in pathnames on Windows.
>       ARGH...Help? (Bruno Friedmann)
>    8. Re: Using multiple drives (Jesper Krogh)
>    9. hang immediately after "Start UA server" (Jo Rhett)
>   10. Re: hang immediately after "Start UA server" (Dan Langille)
>   11. Re: hang immediately after "Start UA server" (Jo Rhett)
>   12. Re: [Bacula-devel] VirtualFull backup: bacula selects the
>       wrong read device (Nicolae Mihalache)
>   13. Re: [Bacula-devel] VirtualFull backup: bacula   selects the
>       wrong read device (Kern Sibbald)
>   14. Re: hang immediately after "Start UA server" (Dan Langille)
>   15. Re: hang immediately after "Start UA server" (Dan Langille)
>   16. Re: [Bacula-devel] VirtualFull backup: bacula   selects the
>       wrong read device (Kern Sibbald)
>   17. Re: [Bacula-devel] VirtualFull backup: bacula selects the
>       wrong read device (Nicolae Mihalache)
>   18. Re: [Bacula-devel] VirtualFull backup: bacula   selects the
>       wrong read device (Kern Sibbald)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: 9 Oct 2009 19:17:07 +0200
> From: florian.schuerfeld AT nunet DOT de
> Subject: [Bacula-users] No longer working with nunet
> To: bacula-users AT lists.sourceforge DOT net
> Message-ID: <20091009171707.25501.qmail AT merkur02.nunet DOT de>
> Content-Type: text/plain; charset="UTF-8"
> 
> Dear Sender,
> 
> i am no longer working with nunet. Your mail will not be forworded.
> Please direct all mail to nunet Operations Team (operations AT nunet DOT de)
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 9 Oct 2009 21:30:19 +0200
> From: Kern Sibbald <kern AT sibbald DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] Minor feature request (just
>       something that would be handy, pretty low priority)
> To: bacula-devel AT lists.sourceforge DOT net
> Cc: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <200910092130.19498.kern AT sibbald DOT com>
> Content-Type: text/plain;  charset="utf-8"
> 
> On Friday 09 October 2009 19:00:58 Blake Dunlap wrote:
> > Item n:   single release command that releases all drives in an auto
> > changer in sequence Origin: Blake Dunlap (blake AT nxs DOT net)
> >   Date:   10/07/2009
> >   Status: Request
> >
> >   What:   It would be nice if there was a release command that would
> > release all drives in an autochanger instead of having to do each one in
> > turn.
> >
> >   Why:    It can take some time for a release to occur, and the commands
> > must be given for each drive in turn, which can quicky scale if there
> are
> > several drives in the library. (Having to watch the console, to give
> each
> > command can waste a good bit of time when you start getting into the 16
> > drive range when the tapes can take up to 3 minutes to eject each)
> >
> >   Notes:  Due  to the way some autochangers/libraries work, you cannot
> > assume that new tapes inserted will go into slots that are not currently
> > believed to be in use by bacula (the tape from that slot is in a drive).
> > This would make any changes in configuration quicker/easier, as all
> drives
> > need to be released before any modifications to slots.
> 
> Added to the projects file.
> 
> Kern
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 09 Oct 2009 14:36:14 -0500
> From: Sean M Clark <smclark AT tamu DOT edu>
> Subject: [Bacula-users] "ClientRunBeforeJob" - spaces in pathnames on
>       Windows. ARGH...Help?
> To: bacula-users AT lists.sourceforge DOT net
> Message-ID: <4ACF90AE.8020605 AT tamu DOT edu>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> We've got several machines where Symantec Antivirus appears to butt in
> and bog down file tranfers severely as it apparently scans every single
> file before it's transferred (or at least this is what I believe is
> happening).
> 
> Previously, we found that we could temporarily halt Symantec at the
> start of a backup job with an appropriate call to smc.exe via
> "ClientRunBeforeJob" and then re-enable it similarly once the backup was
> done.
> 
> The problem is, I could never manage to get "ClientRunBeforeJob" to
> correctly pass the full pathname with spaces in it, despite trying every
> combination of single-quotes, double-quotes, escaped spaces (i.e.
> "C:\\Program\ Files\\" or for that matter "C:/Program\ Files") that I
> could think of.  I was able to get it to work using the old-school
> mangled DOS filenames ("C:\Progra~1\Symant~1\Smc.exe").  However, these
> clients appear to have been moved to new "Vista 64" boxes, and bacula-fd
> is complaining that these paths don't exist anymore.
> 
> Rather than muddling around with guessing the mangling of THIS set of
> directories (or watching backups run at ~200kB/s for days...), can
> anyone give me some hints about how to properly pass pathnames with
> spaces to the Windows bacula-fd in ClientRun(Before|After)Job directives?
> 
> (There also seems to be an unrelated problem with the 3.0.2 64-bit
> Windows client installer, but I think I've just about got that one
> figured out.  I'll report that separately when I'm more confident I know
> what's going on.)
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 9 Oct 2009 21:53:14 +0200
> From: Kern Sibbald <kern AT sibbald DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] [FEATURE REQUEST] convert
>       two full backups to one full and one    reverse incremental (or
>       decremental?)
> To: bacula-devel AT lists.sourceforge DOT net,        Gavin McCullagh
>       <gavin.mccullagh AT gcd DOT ie>
> Cc: Bacula Users List <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <200910092153.14573.kern AT sibbald DOT com>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On Monday 05 October 2009 13:21:44 Gavin McCullagh wrote:
> > Hi,
> >
> > following up on the previous discussion, below is a feature request
> form.
> >
> >
> http://www.mail-archive.com/bacula-devel AT lists.sourceforge DOT 
> net/msg04962.htm
> >l
> >
> > Any comments welcome,
> >
> > Gavin
> >
> >
> ---------------------------------------------------------------------------
> >-- Item n:   Implement a Migration job type that will create a reverse
> > incremental (or decremental) backup from two existing full backups.
> Date:  
> > 05 October 2009
> >   Origin: Griffith College Dublin.  Some sponsorship available.
> >           Contact: Gavin McCullagh <gavin.mccullagh AT gcd DOT ie>
> >   Status:
> >
> >   What:   The ability to take two full backup jobs and derive a reverse
> >       incremental backup from them.  The older full backup data may then
> >           be discarded.
> >
> >   Why:    Long-term backups based on keeping full backups can be
> expensive
> > in media.  In many cases (eg a NAS), as the client accumulates files
> over
> > months and years, the same file will be duplicated unchanged, across
> many
> > media and datasets.  Eg, Less than 10% (and
> >       shrinking) of our monthly full mail server backup is new files,
> >           the other 90% is also in the previous full backup.
> >       Regularly converting the oldest full backup into a reverse
> >       incremental backup allows the admin to keep access to old backup
> >       jobs, but remove all of the duplicated files, freeing up media.
> >
> >   Notes:  This feature was previously discussed on the bacula-devel list
> >       here:
> >
> http://www.mail-archive.com/bacula-devel AT lists.sourceforge DOT 
> net/msg04962.htm
> 
> I have added this feature request to the projects file.
> 
> Regards,
> 
> Kern
> 
> >l
> >
> >
> ---------------------------------------------------------------------------
> >--
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------------
> >--- Come build with us! The BlackBerry&reg; Developer Conference in SF,
> CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and
> stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Bacula-devel mailing list
> > Bacula-devel AT lists.sourceforge DOT net
> > https://lists.sourceforge.net/lists/listinfo/bacula-devel
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Sat, 10 Oct 2009 00:12:07 +0000 (UTC)
> From: Markus Falb <markus.falb AT fasel DOT at>
> Subject: Re: [Bacula-users] "ClientRunBeforeJob" - spaces in pathnames
>       on      Windows. ARGH...Help?
> To: bacula-users AT lists.sourceforge DOT net
> Message-ID: <haojgn$i5k$1 AT ger.gmane DOT org>
> Content-Type: text/plain; charset=UTF-8
> 
> Sean M Clark wrote:
> 
> > The problem is, I could never manage to get "ClientRunBeforeJob" to
> > correctly pass the full pathname with spaces in it, despite trying every
> > combination of single-quotes, double-quotes, escaped spaces (i.e.
> > "C:\\Program\ Files\\" or for that matter "C:/Program\ Files") that I
> > could think of.
> 
> did you try with wrapping quotes like this ?
> "\"C:/Program Files\""
> 
> I realize you said you tried every combination, sorry, but maybe you 
> forgot this one ;-)
> 
> -- 
> best regards,
> markus
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Sat, 10 Oct 2009 01:50:03 -0700 (PDT)
> From: ebollengier <eric AT eb.homelinux DOT org>
> Subject: Re: [Bacula-users] "ClientRunBeforeJob" - spaces in pathnames
>       on Windows. ARGH...Help?
> To: bacula-users AT lists.sourceforge DOT net
> Message-ID: <25832225.post AT talk.nabble DOT com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> 
> Sean M Clark wrote:
> > 
> > We've got several machines where Symantec Antivirus appears to butt in
> > and bog down file tranfers severely as it apparently scans every single
> > file before it's transferred (or at least this is what I believe is
> > happening).
> > 
> > Previously, we found that we could temporarily halt Symantec at the
> > start of a backup job with an appropriate call to smc.exe via
> > "ClientRunBeforeJob" and then re-enable it similarly once the backup was
> > done.
> > 
> > The problem is, I could never manage to get "ClientRunBeforeJob" to
> > correctly pass the full pathname with spaces in it, despite trying every
> > combination of single-quotes, double-quotes, escaped spaces (i.e.
> > "C:\\Program\ Files\\" or for that matter "C:/Program\ Files") that I
> > could think of.  I was able to get it to work using the old-school
> > mangled DOS filenames ("C:\Progra~1\Symant~1\Smc.exe").  However, these
> > clients appear to have been moved to new "Vista 64" boxes, and bacula-fd
> > is complaining that these paths don't exist anymore.
> > 
> > Rather than muddling around with guessing the mangling of THIS set of
> > directories (or watching backups run at ~200kB/s for days...), can
> > anyone give me some hints about how to properly pass pathnames with
> > spaces to the Windows bacula-fd in ClientRun(Before|After)Job
> directives?
> > 
> > (There also seems to be an unrelated problem with the 3.0.2 64-bit
> > Windows client installer, but I think I've just about got that one
> > figured out.  I'll report that separately when I'm more confident I know
> > what's going on.)
> > 
> 
> Perhaps you can start reading the manual section about RunScript on
> windows,
> it gives advices and example on how to handle spaces, accent and other
> funny
> things on Micro$oft environment.
> 
> http://www.bacula.org/3.0.x-manuals/en/install/install/Configuring_Director.html#SECTION00630000000000000000
> 
> Bye
> -- 
> View this message in context:
> http://www.nabble.com/%22ClientRunBeforeJob%22---spaces-in-pathnames-on-Windows.-ARGH...Help--tp25826866p25832225.html
> Sent from the Bacula - Users mailing list archive at Nabble.com.
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Sat, 10 Oct 2009 14:03:00 +0200
> From: Bruno Friedmann <bruno AT ioda-net DOT ch>
> Subject: Re: [Bacula-users] "ClientRunBeforeJob" - spaces in pathnames
>       on Windows. ARGH...Help?
> Cc: bacula-users AT lists.sourceforge DOT net
> Message-ID: <4AD077F4.80101 AT ioda-net DOT ch>
> Content-Type: text/plain; charset=UTF-8
> 
> Sean M Clark wrote:
> > We've got several machines where Symantec Antivirus appears to butt in
> > and bog down file tranfers severely as it apparently scans every single
> > file before it's transferred (or at least this is what I believe is
> > happening).
> > 
> > Previously, we found that we could temporarily halt Symantec at the
> > start of a backup job with an appropriate call to smc.exe via
> > "ClientRunBeforeJob" and then re-enable it similarly once the backup was
> > done.
> > 
> 
> Don't know if you can ( I know that's possible to f-secure and CA eTrust
> Inoculate ) to add a process exception
> (for example exclude the bacula-fd.exe process from realtime scanning)
> Usually I put this inside a policy which is apply to all computers on the
> network.
> 
> 
> 
> -- 
> 
>      Bruno Friedmann
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Sat, 10 Oct 2009 14:11:39 +0200
> From: Jesper Krogh <jesper AT krogh DOT cc>
> Subject: Re: [Bacula-users] Using multiple drives
> To: bacula-users AT lists.sourceforge DOT net
> Message-ID: <4AD079FB.1010000 AT krogh DOT cc>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> tpcshadow wrote:
> > If I run one job (say job A to pool A), the tape from pool A stays in
> > drive 0. After that has finished, if I start another job (say job B
> > to pool B), the library will remove the pool A tape from drive 0 and
> > replace it with the pool B tape in drive 0.
> 
> I think that is just "how it works". I suppose it is due to the amount
> of people really having "spare" drives are very few, in my setup I have
> 2 x LTO3.. and I have the same scenarie, drive 0 basically ends up
> taking all incremental work and some differential + full working every
> day, but drive 1 is only used during high load (weekends with
> full/differential runs).
> 
> Without having looked into the code, I would suspect it to be af fairly
> trivial patch. I'll suggest you to look into it or at least sending a
> feature request for the Projects-file for the project.
> 
> -- 
> Jesper
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Sat, 10 Oct 2009 11:00:40 -0700
> From: Jo Rhett <jrhett AT netconsonance DOT com>
> Subject: [Bacula-users] hang immediately after "Start UA server"
> To: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <9A323965-3E69-4E34-8E2D-21FBF80715BA AT netconsonance DOT com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> I've just upgraded a machine from FreeBSD 6.3 to 7.2.   I replaced all  
> the ports with new versions compiled on 7.2, and everything is working  
> normally (just like every other server running these builds) except  
> for bacula-dir.   It is hanging right after starting the UA server,  
> and before it starts accepting network connections.  From my reading  
> it is hanging in the _umtx_op() call.  No core, no log message,  
> nothing -- except that you have to kill -9 the process.
> 
> I found one other report about this in the archives but they said  
> updating gettext fixed it.  I recompiled those to be sure.  I even  
> recompiled bacula with NLS disabled so that gettext wasn't linked it,  
> and the problem doesn't change.   I'm making no headway on this, and  
> would appreciate some direction on other things to test/debug:
> 
> /usr/local/sbin/bacula-dir -d300 -f -v
> bacula-dir: dird.c:184-0 Debug level = 300
> bacula-dir: runscript.c:296-0 runscript: debug
> bacula-dir: runscript.c:297-0  --> RunScript
> bacula-dir: runscript.c:298-0   --> Command=/usr/local/share/bacula/ 
> make_catalog_backup bacula bacula *snip* localhost
> bacula-dir: runscript.c:299-0   --> Target=
> bacula-dir: runscript.c:300-0   --> RunOnSuccess=1
> bacula-dir: runscript.c:301-0   --> RunOnFailure=0
> bacula-dir: runscript.c:302-0   --> FailJobOnError=1
> bacula-dir: runscript.c:303-0   --> RunWhen=2
> bacula-dir: runscript.c:296-0 runscript: debug
> bacula-dir: runscript.c:297-0  --> RunScript
> bacula-dir: runscript.c:298-0   --> Command=/usr/local/share/bacula/ 
> delete_catalog_backup
> bacula-dir: runscript.c:299-0   --> Target=
> bacula-dir: runscript.c:300-0   --> RunOnSuccess=1
> bacula-dir: runscript.c:301-0   --> RunOnFailure=0
> bacula-dir: runscript.c:302-0   --> FailJobOnError=1
> bacula-dir: runscript.c:303-0   --> RunWhen=1
> bacula-dir: message.c:263-0 Copy message resource 2870f1b8 to 28714698
> bacula-dir: bsys.c:503-0 Could not open state file. sfd=-1 size=188:  
> ERR=No such file or directory
> bacula-dir: mysql.c:101-0 db_open first time
> bacula-dir: mysql.c:130-0 initdb ref=1 connected=0 db=0
> bacula-dir: mysql.c:166-0 mysql_init done
> bacula-dir: mysql.c:187-0 mysql_real_connect done
> bacula-dir: mysql.c:189-0 db_user=bacula db_name=bacula  
> db_password=*snip*
> bacula-dir: mysql.c:215-0 opendb ref=1 connected=1 db=28708044
> bacula-dir: sql_create.c:341-0 In create mediatype
> bacula-dir: sql_create.c:344-0 selectmediatype: SELECT  
> MediaTypeId,MediaType FROM MediaType WHERE MediaType='File_SVcolo'
> bacula-dir: mysql.c:236-0 closedb ref=0 connected=1 db=28708044
> bacula-dir: mysql.c:240-0 close db=28708044
> backup0-dir: dird.c:317-0 Start UA server
> 
> FWIW, it's not the state file error.   I didn't used to get that error  
> until I removed all files trying to see if something in the  
> environment was confusing it.   Exact same process, same hang in the  
> same place whether the state file was there or not.
> 
> Here is the ktrace (similar to strace on linux) output near the  
> failure.  From my reading it is hanging in the _umtx_op() call.
> 
> 91887 bacula-dir GIO   fd 1 wrote 44 bytes
>        "bacula-dir: mysql.c:240-0 close db=28708044
>        "
> 91887 bacula-dir RET   write 44/0x2c
> 91887 bacula-dir CALL  write(0x4,0x28763000,0x5)
> 91887 bacula-dir GIO   fd 4 wrote 5 bytes
>        0x0000 0100 0000  
> 01                                                                      
> |.....|
> 
> 91887 bacula-dir RET   write 5
> 91887 bacula-dir CALL  shutdown(0x4,<invalid=2>)
> 91887 bacula-dir RET   shutdown 0
> 91887 bacula-dir CALL  close(0x4)
> 91887 bacula-dir RET   close 0
> 91887 bacula-dir CALL  __sysctl(0xbfbfe88c, 
> 0x2,0x2815eea0,0xbfbfe8a4,0,0)
> 91887 bacula-dir RET   __sysctl 0
> 91887 bacula-dir CALL  sigaction(SIGHUP,0xbfbfecb4,0xbfbfec9c)
> 91887 bacula-dir RET   sigaction 0
> 91887 bacula-dir CALL  open(0x2815eee0,O_RDWR|O_CREAT,S_IRUSR|S_IWUSR)
> 91887 bacula-dir NAMI  "/var/db/bacula/backup0-dir.conmsg"
> 91887 bacula-dir RET   open 4
> 91887 bacula-dir CALL  lseek(0x4,0,SEEK_SET,0x2)
> 91887 bacula-dir RET   lseek 0
> 91887 bacula-dir CALL  close(0x4)
> 91887 bacula-dir RET   close 0
> 91887 bacula-dir CALL  open(0x2815eee0,O_RDWR|O_APPEND|O_CREAT,S_IRUSR| 
> S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
> 91887 bacula-dir NAMI  "/var/db/bacula/backup0-dir.conmsg"
> 91887 bacula-dir RET   open 4
> 91887 bacula-dir CALL  lseek(0x4,0,SEEK_SET,0x2)
> 91887 bacula-dir RET   lseek 0
> 91887 bacula-dir CALL  write(0x1,0x28711000,0x2a)
> 91887 bacula-dir GIO   fd 1 wrote 42 bytes
>        "backup0-dir: dird.c:317-0 Start UA server
>        "
> 91887 bacula-dir RET   write 42/0x2a
> 91887 bacula-dir CALL  _umtx_op(0xbfbfebd0,0x3,0x1,0,0)
> 91887 bacula-dir RET   _umtx_op 0
> 91887 bacula-dir CALL  sigprocmask(SIG_BLOCK,0xbfbfeb74,0x287010d8)
> 91887 bacula-dir RET   sigprocmask 0
> 91887 bacula-dir CALL  sigprocmask(SIG_SETMASK,0x287010d8,0)
> 91887 bacula-dir RET   sigprocmask 0
> 91887 bacula-dir CALL  _umtx_op(0x281daa80,0x11,0,0,0)
> 91887 bacula-dir RET   _umtx_op -1 errno 4 Interrupted system call
> 91887 bacula-dir PSIG  SIGINT SIG_DFL
> 
> Machine: Rackable 3U with single-core Athlon
> CPU: AMD Opteron(tm) Processor 244 (1804.10-MHz 686-class CPU)
>   Origin = "AuthenticAMD"  Id = 0xf5a  Stepping = 10
> Features 
> = 
> 0x78bfbff 
> < 
> FPU 
> ,VME 
> ,DE 
> ,PSE 
> ,TSC 
> ,MSR 
> ,PAE 
> ,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
>   AMD Features=0xe0500800<SYSCALL,NX,MMX+,LM,3DNow!+,3DNow!>
> real memory  = 2146828288 (2047 MB)
> 
> This exact machine and hardware have been running FreeBSD 6.x and  
> Bacula for >2 years now, zero problems.
> 
> -- 
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source  
> and other randomness
> 
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Sat, 10 Oct 2009 19:59:42 -0400
> From: Dan Langille <dan AT langille DOT org>
> Subject: Re: [Bacula-users] hang immediately after "Start UA server"
> To: Jo Rhett <jrhett AT netconsonance DOT com>
> Cc: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <4AD11FEE.5080400 AT langille DOT org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Jo Rhett wrote:
> > I've just upgraded a machine from FreeBSD 6.3 to 7.2.   I replaced all  
> > the ports with new versions compiled on 7.2, and everything is working  
> > normally (just like every other server running these builds) except  
> > for bacula-dir.   It is hanging right after starting the UA server,  
> > and before it starts accepting network connections.  From my reading  
> > it is hanging in the _umtx_op() call.  No core, no log message,  
> > nothing -- except that you have to kill -9 the process.
> 
> Ouch.
> 
> Let me run some regression tests on 7.2 with MySQL.  I usually do this 
> only with PostgreSQL (because it's what I use). Perhaps you could also 
> run the tests and we can compare results.
> 
> > This exact machine and hardware have been running FreeBSD 6.x and  
> > Bacula for >2 years now, zero problems.
> 
> FWIW: FreeBSD 7.2-STABLE #0: Mon Aug 17 09:31:39
> 
> Are you on FreeBSD release or the latest stable?
> 
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Sat, 10 Oct 2009 23:34:10 -0700
> From: Jo Rhett <jrhett AT netconsonance DOT com>
> Subject: Re: [Bacula-users] hang immediately after "Start UA server"
> To: Dan Langille <dan AT langille DOT org>
> Cc: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <9524BBF4-8964-40FB-9041-FF7E7D4B47D8 AT netconsonance DOT com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> On Oct 10, 2009, at 4:59 PM, Dan Langille wrote:
> > Jo Rhett wrote:
> >> I've just upgraded a machine from FreeBSD 6.3 to 7.2.   I replaced  
> >> all  the ports with new versions compiled on 7.2, and everything is  
> >> working  normally (just like every other server running these  
> >> builds) except  for bacula-dir.   It is hanging right after  
> >> starting the UA server,  and before it starts accepting network  
> >> connections.  From my reading  it is hanging in the _umtx_op()  
> >> call.  No core, no log message,  nothing -- except that you have to  
> >> kill -9 the process.
> >
> > Let me run some regression tests on 7.2 with MySQL.  I usually do  
> > this only with PostgreSQL (because it's what I use). Perhaps you  
> > could also run the tests and we can compare results.
> 
> Sure.  Point me where to find the regression tests?  My google foo is  
> coming up blank.   And FWIW, I don't think it's a mysql thing.   I  
> changed databases to use a fresh mysql DB and this still occurs.  And  
> my reading of ktrace says that all DB connections are closed at the  
> time this occurs.   Would you like the raw ktrace of the process, or  
> anything from it to help?
> 
> >> This exact machine and hardware have been running FreeBSD 6.x and   
> >> Bacula for >2 years now, zero problems.
> >
> > FWIW: FreeBSD 7.2-STABLE #0: Mon Aug 17 09:31:39
> > Are you on FreeBSD release or the latest stable?
> 
> 
> FreeBSD backup0.sv 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct   
> 2 12:21:39 UTC 2009     root AT i386-builder.daemonology DOT 
> net:/usr/obj/usr/ 
> src/sys/GENERIC  i386
> 
> -- 
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source  
> and other randomness
> 
> 
> 
> 
> ------------------------------
> 
> Message: 12
> Date: Sun, 11 Oct 2009 12:56:05 +0200
> From: Nicolae Mihalache <mache AT abcpages DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] VirtualFull backup: bacula
>       selects the wrong read device
> To: Kern Sibbald <kern AT sibbald DOT com>
> Cc: bacula-devel AT lists.sourceforge DOT net,
>       bacula-users AT lists.sourceforge DOT net
> Message-ID: <4AD1B9C5.1030500 AT abcpages DOT com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I investigated a little more and found that if I replace the line
> 
>     rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> rctx.device->dev);
> 
> with
>    if (rctx.store->append == SD_READ) {
>       rctx.jcr->read_dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->read_dcr,
> rctx.device->dev);
>    } else {
>       rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> rctx.device->dev);
>    }
> 
> in reserve.c:637, it will work ok.
> I was confused by the function new_dcr which despite its name, doesn't
> create a new dcr if it already exists ( I think the name should be
> changed).
> 
> nicolae
> 
> 
> Kern Sibbald wrote:
> > On Friday 09 October 2009 15:06:36 Nicolae Mihalache wrote:
> >   
> >> Sorry, I'm not quite sure I grasp your message.
> >> When you refer to Storage in "Changing Storage for restore and
> >> migration", you talk about Storage Daemon or the Storage resource in
> the
> >> director?
> >>     
> >
> > I was not very precise.  I meant that changing Storage daemons is not 
> > supported in any released version.  Changing storage devices is also not
> > officially supported in any released version, but there is code that
> seems to 
> > work in most cases.
> >
> >   
> >> I have one Storage Daemon with three different devices and three
> >> corresponding storage resources in the director. What I want to do is
> to
> >> read from two of those devices and write into the third one.
> >> Changing between the two reading ones is not working. I did a bit of
> >> debugging, and I found that:
> >>
> >> In stored/acquire.c
> >>
> >>       stat = search_res_for_device(rctx);
> >>       release_reserve_messages(jcr);         /* release queued messages
> */
> >>       unlock_reservations();
> >>
> >>       if (stat == 1) {
> >>          dev = dcr->dev;                     /* get new device pointer
> */
> >>
> >> In stored/reserve.c:
> >>
> >>  ok = reserve_device_for_read(dcr);
> >>       if (ok) {
> >>          rctx.jcr->read_dcr = dcr;
> >>
> >>
> >> So basically the jcr->read_dcr is changed to point to a brand new dcr
> in
> >> reserve.c but the code in acquire.c is using the old dcr. Also in
> >> acquire.c there is a comment that says dcr pointer shouldn't change.
> >>     
> >
> > If indeed the code in reserve.c is setting an entirely new dcr pointer,
> then 
> > it is unlikely the code will work.  So that may be the problem you are 
> > running into.  However, in all our tests, it does seem to work providing
> you 
> > have different MediaTypes for each device. Though as I say, it is not 
> > officially supported, simply because I don't have enough confidence in
> the 
> > code. If you have the same MediaType for different devices, then
> switching 
> > devices won't work.
> >
> > Regards,
> >
> > Kern
> >
> >   
> >> nicolae
> >>
> >> Kern Sibbald wrote:
> >>     
> >>> Hello,
> >>>
> >>> You are attempting to use a feature that is not implemented.
> >>>
> >>> Changing Storage for restore and migration is not implemented in any
> >>> released version of Bacula.
> >>>
> >>> Changing of Storage for restore is implemented in 3.1.x (not yet
> >>> released). However, it is unlikely that it works for migration.
> >>>
> >>> Changing of devices within a given Storage should be implemented, for
> >>> reading of any kind, but we do not guarantee that it works -- in your
> >>> email, you did not specify much information so I cannot be more
> specific.
> >>>
> >>> Regards,
> >>>
> >>> Kern
> >>>
> >>> On Friday 09 October 2009 12:37:50 Nicolae Mihalache wrote:
> >>>       
> >>>> Hello,
> >>>>
> >>>> I run Full backups on MediaType=LOT-4 and Incremental backups on
> >>>> MediaType=File. When running a VirtualFull into a tmp pool
> >>>> (MediaType=TmpFile), bacula starts correctly reading the full backup
> >>>> from LTO-4. However, when the Incremental starts, it still wants to
> use
> >>>> the LTO-4 device instead of switching to the file device:
> >>>>
> >>>> 09-Oct 11:43 bacula-sd JobId 8889: End of Volume at file 46 on device
> >>>> "HP" (/dev/st0), Volume "GROUPS-01" 09-Oct 11:44 bacula-sd JobId
> 8889:
> >>>> acquire.c:116 Changing read device. Want Media Type="File"
> have="LTO-4"
> >>>> device="HP" (/dev/st0) 09-Oct 11:44 bacula-sd JobId 8889: Media Type
> >>>> change.  New read device "HP" (/dev/st0) chosen. 09-Oct 11:44
> bacula-sd
> >>>> JobId 8889: Invalid slot=0 defined in catalog for Volume
> "aa-work-0125"
> >>>> on "HP" (/dev/st0). Manual load may be required.
> >>>>
> >>>> >From these logs it seems it wants to change the read device but for
> >>>>         
> >>>>> some
> >>>>>           
> >>>> reason selects the same (wrong) one.
> >>>>
> >>>>
> >>>> Thanks for any hints.
> >>>> nicolae
> >>>>         
> >>
> ---------------------------------------------------------------------------
> >> --- Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA is
> >> the only developer event you need to attend this year. Jumpstart your
> >> developing skills, take BlackBerry mobile applications to market and
> stay
> >> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> Bacula-devel mailing list
> >> Bacula-devel AT lists.sourceforge DOT net
> >> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> >>     
> >
> >   
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 13
> Date: Sun, 11 Oct 2009 14:09:56 +0200
> From: Kern Sibbald <kern AT sibbald DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] VirtualFull backup: bacula
>       selects the wrong read device
> To: bacula-devel AT lists.sourceforge DOT net
> Cc: bacula-users AT lists.sourceforge DOT net
> Message-ID: <200910111409.57162.kern AT sibbald DOT com>
> Content-Type: text/plain;  charset="utf-8"
> 
> Hello,
> 
> That is *very* interesting.  Thanks for looking into this.  I think the
> code 
> has previously worked for us because we may not have explicitly tested 
> Migration and VirtualFull, but for restores it all works fine.
> 
> Could you try one change to your fix?  Remove your fix, then change line
> 
> reserve.c:637 from:
> 
>    rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> rctx.device->dev);
> 
> to
> 
>    dcr = new_dcr(rctx.jcr, rctx.jcr->dcr, rctx.device->dev);
> 
> I think this will solve the problem in a slightly cleaner way.
> 
> If the above works, I'll be happy to integrate it and get it out in 3.0.3
> 
> Best regards,
> 
> Kern
>     
> 
> 
> On Sunday 11 October 2009 12:56:05 Nicolae Mihalache wrote:
> > I investigated a little more and found that if I replace the line
> >
> >     rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > rctx.device->dev);
> >
> > with
> >    if (rctx.store->append == SD_READ) {
> >       rctx.jcr->read_dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->read_dcr,
> > rctx.device->dev);
> >    } else {
> >       rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > rctx.device->dev);
> >    }
> >
> > in reserve.c:637, it will work ok.
> > I was confused by the function new_dcr which despite its name, doesn't
> > create a new dcr if it already exists ( I think the name should be
> > changed).
> >
> > nicolae
> >
> > Kern Sibbald wrote:
> > > On Friday 09 October 2009 15:06:36 Nicolae Mihalache wrote:
> > >> Sorry, I'm not quite sure I grasp your message.
> > >> When you refer to Storage in "Changing Storage for restore and
> > >> migration", you talk about Storage Daemon or the Storage resource in
> the
> > >> director?
> > >
> > > I was not very precise.  I meant that changing Storage daemons is not
> > > supported in any released version.  Changing storage devices is also
> not
> > > officially supported in any released version, but there is code that
> > > seems to work in most cases.
> > >
> > >> I have one Storage Daemon with three different devices and three
> > >> corresponding storage resources in the director. What I want to do is
> to
> > >> read from two of those devices and write into the third one.
> > >> Changing between the two reading ones is not working. I did a bit of
> > >> debugging, and I found that:
> > >>
> > >> In stored/acquire.c
> > >>
> > >>       stat = search_res_for_device(rctx);
> > >>       release_reserve_messages(jcr);         /* release queued
> messages
> > >> */ unlock_reservations();
> > >>
> > >>       if (stat == 1) {
> > >>          dev = dcr->dev;                     /* get new device
> pointer
> > >> */
> > >>
> > >> In stored/reserve.c:
> > >>
> > >>  ok = reserve_device_for_read(dcr);
> > >>       if (ok) {
> > >>          rctx.jcr->read_dcr = dcr;
> > >>
> > >>
> > >> So basically the jcr->read_dcr is changed to point to a brand new dcr
> in
> > >> reserve.c but the code in acquire.c is using the old dcr. Also in
> > >> acquire.c there is a comment that says dcr pointer shouldn't change.
> > >
> > > If indeed the code in reserve.c is setting an entirely new dcr
> pointer,
> > > then it is unlikely the code will work.  So that may be the problem
> you
> > > are running into.  However, in all our tests, it does seem to work
> > > providing you have different MediaTypes for each device. Though as I
> say,
> > > it is not officially supported, simply because I don't have enough
> > > confidence in the code. If you have the same MediaType for different
> > > devices, then switching devices won't work.
> > >
> > > Regards,
> > >
> > > Kern
> > >
> > >> nicolae
> > >>
> > >> Kern Sibbald wrote:
> > >>> Hello,
> > >>>
> > >>> You are attempting to use a feature that is not implemented.
> > >>>
> > >>> Changing Storage for restore and migration is not implemented in any
> > >>> released version of Bacula.
> > >>>
> > >>> Changing of Storage for restore is implemented in 3.1.x (not yet
> > >>> released). However, it is unlikely that it works for migration.
> > >>>
> > >>> Changing of devices within a given Storage should be implemented,
> for
> > >>> reading of any kind, but we do not guarantee that it works -- in
> your
> > >>> email, you did not specify much information so I cannot be more
> > >>> specific.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Kern
> > >>>
> > >>> On Friday 09 October 2009 12:37:50 Nicolae Mihalache wrote:
> > >>>> Hello,
> > >>>>
> > >>>> I run Full backups on MediaType=LOT-4 and Incremental backups on
> > >>>> MediaType=File. When running a VirtualFull into a tmp pool
> > >>>> (MediaType=TmpFile), bacula starts correctly reading the full
> backup
> > >>>> from LTO-4. However, when the Incremental starts, it still wants to
> > >>>> use the LTO-4 device instead of switching to the file device:
> > >>>>
> > >>>> 09-Oct 11:43 bacula-sd JobId 8889: End of Volume at file 46 on
> device
> > >>>> "HP" (/dev/st0), Volume "GROUPS-01" 09-Oct 11:44 bacula-sd JobId
> 8889:
> > >>>> acquire.c:116 Changing read device. Want Media Type="File"
> > >>>> have="LTO-4" device="HP" (/dev/st0) 09-Oct 11:44 bacula-sd JobId
> 8889:
> > >>>> Media Type change.  New read device "HP" (/dev/st0) chosen. 09-Oct
> > >>>> 11:44 bacula-sd JobId 8889: Invalid slot=0 defined in catalog for
> > >>>> Volume "aa-work-0125" on "HP" (/dev/st0). Manual load may be
> required.
> > >>>>
> > >>>> >From these logs it seems it wants to change the read device but
> for
> > >>>>>
> > >>>>> some
> > >>>>
> > >>>> reason selects the same (wrong) one.
> > >>>>
> > >>>>
> > >>>> Thanks for any hints.
> > >>>> nicolae
> > >>
> > >>
> ------------------------------------------------------------------------
> > >>--- --- Come build with us! The BlackBerry(R) Developer Conference in
> SF,
> > >> CA is the only developer event you need to attend this year.
> Jumpstart
> > >> your developing skills, take BlackBerry mobile applications to market
> > >> and stay ahead of the curve. Join us from November 9 - 12, 2009.
> > >> Register now! http://p.sf.net/sfu/devconference
> > >> _______________________________________________
> > >> Bacula-devel mailing list
> > >> Bacula-devel AT lists.sourceforge DOT net
> > >> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 14
> Date: Sun, 11 Oct 2009 08:12:21 -0400
> From: Dan Langille <dan AT langille DOT org>
> Subject: Re: [Bacula-users] hang immediately after "Start UA server"
> To: Jo Rhett <jrhett AT netconsonance DOT com>
> Cc: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <4AD1CBA5.9070208 AT langille DOT org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Jo Rhett wrote:
> > On Oct 10, 2009, at 4:59 PM, Dan Langille wrote:
> >> Jo Rhett wrote:
> >>> I've just upgraded a machine from FreeBSD 6.3 to 7.2.   I replaced 
> >>> all  the ports with new versions compiled on 7.2, and everything is 
> >>> working  normally (just like every other server running these builds) 
> >>> except  for bacula-dir.   It is hanging right after starting the UA 
> >>> server,  and before it starts accepting network connections.  From my 
> >>> reading  it is hanging in the _umtx_op() call.  No core, no log 
> >>> message,  nothing -- except that you have to kill -9 the process.
> >>
> >> Let me run some regression tests on 7.2 with MySQL.  I usually do this 
> >> only with PostgreSQL (because it's what I use). Perhaps you could also 
> >> run the tests and we can compare results.
> > 
> > Sure.  Point me where to find the regression tests?  
> 
> They are in git:
> 
>   http://bacula.git.sourceforge.net/git/gitweb.cgi?p=bacula/bacula;a=tree
> 
> Grab the whole tree from that point (technically, you don't need the 
> gui), cd regress, and follow README.  I never run this on my production 
> Bacula system, just in case it wipes it out.
> 
>  > My google foo is
> > coming up blank.   And FWIW, I don't think it's a mysql thing.   I 
> > changed databases to use a fresh mysql DB and this still occurs.  And my
> > reading of ktrace says that all DB connections are closed at the time 
> > this occurs.   Would you like the raw ktrace of the process, or anything
> > from it to help?
> 
> Sure, you can send it.  It may help.
> 
> There is my regression testing output:
> 
>    http://regress.bacula.org/buildSummary.php?buildid=10165
> 
> 30 tests failed.  However, this is the first regression tests I have run 
> in this system.  It may be a configuration issue.  I have not looked at 
> this.  Perhaps later today.
> 
> > 
> >>> This exact machine and hardware have been running FreeBSD 6.x and  
> >>> Bacula for >2 years now, zero problems.
> >>
> >> FWIW: FreeBSD 7.2-STABLE #0: Mon Aug 17 09:31:39
> >> Are you on FreeBSD release or the latest stable?
> > 
> > 
> > FreeBSD backup0.sv 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct  2 
> > 12:21:39 UTC 2009     
> > root AT i386-builder.daemonology DOT net:/usr/obj/usr/src/sys/GENERIC  i386
> 
> Depending on our respective results, I'm willing to upgrade my system to 
> the latest stable.
> 
> 
> 
> ------------------------------
> 
> Message: 15
> Date: Sun, 11 Oct 2009 08:18:52 -0400
> From: Dan Langille <dan AT langille DOT org>
> Subject: Re: [Bacula-users] hang immediately after "Start UA server"
> To: Jo Rhett <jrhett AT netconsonance DOT com>
> Cc: bacula-users <bacula-users AT lists.sourceforge DOT net>
> Message-ID: <4AD1CD2C.5090509 AT langille DOT org>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> Dan Langille wrote:
> > Jo Rhett wrote:
> >> On Oct 10, 2009, at 4:59 PM, Dan Langille wrote:
> >>> Jo Rhett wrote:
> >>>> I've just upgraded a machine from FreeBSD 6.3 to 7.2.   I replaced 
> >>>> all  the ports with new versions compiled on 7.2, and everything is 
> >>>> working  normally (just like every other server running these builds)
> >>>> except  for bacula-dir.   It is hanging right after starting the UA 
> >>>> server,  and before it starts accepting network connections.  From my
> >>>> reading  it is hanging in the _umtx_op() call.  No core, no log 
> >>>> message,  nothing -- except that you have to kill -9 the process.
> >>> Let me run some regression tests on 7.2 with MySQL.  I usually do this
> >>> only with PostgreSQL (because it's what I use). Perhaps you could also
> >>> run the tests and we can compare results.
> >> Sure.  Point me where to find the regression tests?  
> > 
> > They are in git:
> > 
> >  
> http://bacula.git.sourceforge.net/git/gitweb.cgi?p=bacula/bacula;a=tree
> > 
> > Grab the whole tree from that point (technically, you don't need the 
> > gui), cd regress, and follow README.  I never run this on my production 
> > Bacula system, just in case it wipes it out.
> 
> README.ctest too.
> 
> 
> 
> ------------------------------
> 
> Message: 16
> Date: Sun, 11 Oct 2009 16:15:40 +0200
> From: Kern Sibbald <kern AT sibbald DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] VirtualFull backup: bacula
>       selects the wrong read device
> To: bacula-devel AT lists.sourceforge DOT net
> Cc: bacula-users AT lists.sourceforge DOT net
> Message-ID: <200910111615.40339.kern AT sibbald DOT com>
> Content-Type: text/plain;  charset="utf-8"
> 
> Hello,
> 
> This is to let you know that I have tested my variation of your proposed
> fix 
> for changing read devices during VirtualFull, and it seems to work fine
> here 
> in our tests, so I have committed it.  Just the same, I would appreciate
> it 
> if you could confirm that my suggestion really does fix your problem.
> 
> Best regards,
> 
> Kern
> 
> 
> ======= previous email below ....
> 
> 
> Hello,
> 
> That is *very* interesting.  Thanks for looking into this.  I think the
> code 
> has previously worked for us because we may not have explicitly tested 
> Migration and VirtualFull, but for restores it all works fine.
> 
> Could you try one change to your fix?  Remove your fix, then change line
> 
> reserve.c:637 from:
> 
>    rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> rctx.device->dev);
> 
> to
> 
>    dcr = new_dcr(rctx.jcr, rctx.jcr->dcr, rctx.device->dev);
> 
> I think this will solve the problem in a slightly cleaner way.
> 
> If the above works, I'll be happy to integrate it and get it out in 3.0.3
> 
> Best regards,
> 
> Kern
>     
> 
> 
> On Sunday 11 October 2009 12:56:05 Nicolae Mihalache wrote:
> > I investigated a little more and found that if I replace the line
> >
> >     rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > rctx.device->dev);
> >
> > with
> >    if (rctx.store->append == SD_READ) {
> >       rctx.jcr->read_dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->read_dcr,
> > rctx.device->dev);
> >    } else {
> >       rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > rctx.device->dev);
> >    }
> >
> > in reserve.c:637, it will work ok.
> > I was confused by the function new_dcr which despite its name, doesn't
> > create a new dcr if it already exists ( I think the name should be
> > changed).
> >
> > nicolae
> >
> > Kern Sibbald wrote:
> > > On Friday 09 October 2009 15:06:36 Nicolae Mihalache wrote:
> > >> Sorry, I'm not quite sure I grasp your message.
> > >> When you refer to Storage in "Changing Storage for restore and
> > >> migration", you talk about Storage Daemon or the Storage resource in
> the
> > >> director?
> > >
> > > I was not very precise.  I meant that changing Storage daemons is not
> > > supported in any released version.  Changing storage devices is also
> not
> > > officially supported in any released version, but there is code that
> > > seems to work in most cases.
> > >
> > >> I have one Storage Daemon with three different devices and three
> > >> corresponding storage resources in the director. What I want to do is
> to
> > >> read from two of those devices and write into the third one.
> > >> Changing between the two reading ones is not working. I did a bit of
> > >> debugging, and I found that:
> > >>
> > >> In stored/acquire.c
> > >>
> > >>       stat = search_res_for_device(rctx);
> > >>       release_reserve_messages(jcr);         /* release queued
> messages
> > >> */ unlock_reservations();
> > >>
> > >>       if (stat == 1) {
> > >>          dev = dcr->dev;                     /* get new device
> pointer
> > >> */
> > >>
> > >> In stored/reserve.c:
> > >>
> > >>  ok = reserve_device_for_read(dcr);
> > >>       if (ok) {
> > >>          rctx.jcr->read_dcr = dcr;
> > >>
> > >>
> > >> So basically the jcr->read_dcr is changed to point to a brand new dcr
> in
> > >> reserve.c but the code in acquire.c is using the old dcr. Also in
> > >> acquire.c there is a comment that says dcr pointer shouldn't change.
> > >
> > > If indeed the code in reserve.c is setting an entirely new dcr
> pointer,
> > > then it is unlikely the code will work.  So that may be the problem
> you
> > > are running into.  However, in all our tests, it does seem to work
> > > providing you have different MediaTypes for each device. Though as I
> say,
> > > it is not officially supported, simply because I don't have enough
> > > confidence in the code. If you have the same MediaType for different
> > > devices, then switching devices won't work.
> > >
> > > Regards,
> > >
> > > Kern
> > >
> > >> nicolae
> > >>
> > >> Kern Sibbald wrote:
> > >>> Hello,
> > >>>
> > >>> You are attempting to use a feature that is not implemented.
> > >>>
> > >>> Changing Storage for restore and migration is not implemented in any
> > >>> released version of Bacula.
> > >>>
> > >>> Changing of Storage for restore is implemented in 3.1.x (not yet
> > >>> released). However, it is unlikely that it works for migration.
> > >>>
> > >>> Changing of devices within a given Storage should be implemented,
> for
> > >>> reading of any kind, but we do not guarantee that it works -- in
> your
> > >>> email, you did not specify much information so I cannot be more
> > >>> specific.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Kern
> > >>>
> > >>> On Friday 09 October 2009 12:37:50 Nicolae Mihalache wrote:
> > >>>> Hello,
> > >>>>
> > >>>> I run Full backups on MediaType=LOT-4 and Incremental backups on
> > >>>> MediaType=File. When running a VirtualFull into a tmp pool
> > >>>> (MediaType=TmpFile), bacula starts correctly reading the full
> backup
> > >>>> from LTO-4. However, when the Incremental starts, it still wants to
> > >>>> use the LTO-4 device instead of switching to the file device:
> > >>>>
> > >>>> 09-Oct 11:43 bacula-sd JobId 8889: End of Volume at file 46 on
> device
> > >>>> "HP" (/dev/st0), Volume "GROUPS-01" 09-Oct 11:44 bacula-sd JobId
> 8889:
> > >>>> acquire.c:116 Changing read device. Want Media Type="File"
> > >>>> have="LTO-4" device="HP" (/dev/st0) 09-Oct 11:44 bacula-sd JobId
> 8889:
> > >>>> Media Type change.  New read device "HP" (/dev/st0) chosen. 09-Oct
> > >>>> 11:44 bacula-sd JobId 8889: Invalid slot=0 defined in catalog for
> > >>>> Volume "aa-work-0125" on "HP" (/dev/st0). Manual load may be
> required.
> > >>>>
> > >>>> >From these logs it seems it wants to change the read device but
> for
> > >>>>>
> > >>>>> some
> > >>>>
> > >>>> reason selects the same (wrong) one.
> > >>>>
> > >>>>
> > >>>> Thanks for any hints.
> > >>>> nicolae
> > >>
> > >>
> ------------------------------------------------------------------------
> > >>--- --- Come build with us! The BlackBerry(R) Developer Conference in
> SF,
> > >> CA is the only developer event you need to attend this year.
> Jumpstart
> > >> your developing skills, take BlackBerry mobile applications to market
> > >> and stay ahead of the curve. Join us from November 9 - 12, 2009.
> > >> Register now! http://p.sf.net/sfu/devconference
> > >> _______________________________________________
> > >> Bacula-devel mailing list
> > >> Bacula-devel AT lists.sourceforge DOT net
> > >> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 17
> Date: Sun, 11 Oct 2009 18:32:12 +0200
> From: Nicolae Mihalache <mache AT abcpages DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] VirtualFull backup: bacula
>       selects the wrong read device
> To: Kern Sibbald <kern AT sibbald DOT com>
> Cc: bacula-devel AT lists.sourceforge DOT net,
>       bacula-users AT lists.sourceforge DOT net
> Message-ID: <4AD2088C.4000009 AT abcpages DOT com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hello, I can only test tomorrow because now I have some long running
> backups.
> 
> But isn't your change affecting the jcr->dcr which is the writing device?
> 
> Have you tried running a virtual full or just a restore? I guess for a
> restore it is working because no writing device is being used.
> 
> 
> nicolae
> 
> 
> Kern Sibbald wrote:
> > Hello,
> >
> > That is *very* interesting.  Thanks for looking into this.  I think the
> code 
> > has previously worked for us because we may not have explicitly tested 
> > Migration and VirtualFull, but for restores it all works fine.
> >
> > Could you try one change to your fix?  Remove your fix, then change line
> >
> > reserve.c:637 from:
> >
> >    rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> rctx.device->dev);
> >
> > to
> >
> >    dcr = new_dcr(rctx.jcr, rctx.jcr->dcr, rctx.device->dev);
> >
> > I think this will solve the problem in a slightly cleaner way.
> >
> > If the above works, I'll be happy to integrate it and get it out in
> 3.0.3
> >
> > Best regards,
> >
> > Kern
> >     
> >
> >
> > On Sunday 11 October 2009 12:56:05 Nicolae Mihalache wrote:
> >   
> >> I investigated a little more and found that if I replace the line
> >>
> >>     rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> >> rctx.device->dev);
> >>
> >> with
> >>    if (rctx.store->append == SD_READ) {
> >>       rctx.jcr->read_dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->read_dcr,
> >> rctx.device->dev);
> >>    } else {
> >>       rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> >> rctx.device->dev);
> >>    }
> >>
> >> in reserve.c:637, it will work ok.
> >> I was confused by the function new_dcr which despite its name, doesn't
> >> create a new dcr if it already exists ( I think the name should be
> >> changed).
> >>
> >> nicolae
> >>
> >> Kern Sibbald wrote:
> >>     
> >>> On Friday 09 October 2009 15:06:36 Nicolae Mihalache wrote:
> >>>       
> >>>> Sorry, I'm not quite sure I grasp your message.
> >>>> When you refer to Storage in "Changing Storage for restore and
> >>>> migration", you talk about Storage Daemon or the Storage resource in
> the
> >>>> director?
> >>>>         
> >>> I was not very precise.  I meant that changing Storage daemons is not
> >>> supported in any released version.  Changing storage devices is also
> not
> >>> officially supported in any released version, but there is code that
> >>> seems to work in most cases.
> >>>
> >>>       
> >>>> I have one Storage Daemon with three different devices and three
> >>>> corresponding storage resources in the director. What I want to do is
> to
> >>>> read from two of those devices and write into the third one.
> >>>> Changing between the two reading ones is not working. I did a bit of
> >>>> debugging, and I found that:
> >>>>
> >>>> In stored/acquire.c
> >>>>
> >>>>       stat = search_res_for_device(rctx);
> >>>>       release_reserve_messages(jcr);         /* release queued
> messages
> >>>> */ unlock_reservations();
> >>>>
> >>>>       if (stat == 1) {
> >>>>          dev = dcr->dev;                     /* get new device
> pointer
> >>>> */
> >>>>
> >>>> In stored/reserve.c:
> >>>>
> >>>>  ok = reserve_device_for_read(dcr);
> >>>>       if (ok) {
> >>>>          rctx.jcr->read_dcr = dcr;
> >>>>
> >>>>
> >>>> So basically the jcr->read_dcr is changed to point to a brand new dcr
> in
> >>>> reserve.c but the code in acquire.c is using the old dcr. Also in
> >>>> acquire.c there is a comment that says dcr pointer shouldn't change.
> >>>>         
> >>> If indeed the code in reserve.c is setting an entirely new dcr
> pointer,
> >>> then it is unlikely the code will work.  So that may be the problem
> you
> >>> are running into.  However, in all our tests, it does seem to work
> >>> providing you have different MediaTypes for each device. Though as I
> say,
> >>> it is not officially supported, simply because I don't have enough
> >>> confidence in the code. If you have the same MediaType for different
> >>> devices, then switching devices won't work.
> >>>
> >>> Regards,
> >>>
> >>> Kern
> >>>
> >>>       
> >>>> nicolae
> >>>>
> >>>> Kern Sibbald wrote:
> >>>>         
> >>>>> Hello,
> >>>>>
> >>>>> You are attempting to use a feature that is not implemented.
> >>>>>
> >>>>> Changing Storage for restore and migration is not implemented in any
> >>>>> released version of Bacula.
> >>>>>
> >>>>> Changing of Storage for restore is implemented in 3.1.x (not yet
> >>>>> released). However, it is unlikely that it works for migration.
> >>>>>
> >>>>> Changing of devices within a given Storage should be implemented,
> for
> >>>>> reading of any kind, but we do not guarantee that it works -- in
> your
> >>>>> email, you did not specify much information so I cannot be more
> >>>>> specific.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Kern
> >>>>>
> >>>>> On Friday 09 October 2009 12:37:50 Nicolae Mihalache wrote:
> >>>>>           
> >>>>>> Hello,
> >>>>>>
> >>>>>> I run Full backups on MediaType=LOT-4 and Incremental backups on
> >>>>>> MediaType=File. When running a VirtualFull into a tmp pool
> >>>>>> (MediaType=TmpFile), bacula starts correctly reading the full
> backup
> >>>>>> from LTO-4. However, when the Incremental starts, it still wants to
> >>>>>> use the LTO-4 device instead of switching to the file device:
> >>>>>>
> >>>>>> 09-Oct 11:43 bacula-sd JobId 8889: End of Volume at file 46 on
> device
> >>>>>> "HP" (/dev/st0), Volume "GROUPS-01" 09-Oct 11:44 bacula-sd JobId
> 8889:
> >>>>>> acquire.c:116 Changing read device. Want Media Type="File"
> >>>>>> have="LTO-4" device="HP" (/dev/st0) 09-Oct 11:44 bacula-sd JobId
> 8889:
> >>>>>> Media Type change.  New read device "HP" (/dev/st0) chosen. 09-Oct
> >>>>>> 11:44 bacula-sd JobId 8889: Invalid slot=0 defined in catalog for
> >>>>>> Volume "aa-work-0125" on "HP" (/dev/st0). Manual load may be
> required.
> >>>>>>
> >>>>>> >From these logs it seems it wants to change the read device but
> for
> >>>>>>             
> >>>>>>> some
> >>>>>>>               
> >>>>>> reason selects the same (wrong) one.
> >>>>>>
> >>>>>>
> >>>>>> Thanks for any hints.
> >>>>>> nicolae
> >>>>>>             
> >>>>
> ------------------------------------------------------------------------
> >>>> --- --- Come build with us! The BlackBerry(R) Developer Conference in
> SF,
> >>>> CA is the only developer event you need to attend this year.
> Jumpstart
> >>>> your developing skills, take BlackBerry mobile applications to market
> >>>> and stay ahead of the curve. Join us from November 9 - 12, 2009.
> >>>> Register now! http://p.sf.net/sfu/devconference
> >>>> _______________________________________________
> >>>> Bacula-devel mailing list
> >>>> Bacula-devel AT lists.sourceforge DOT net
> >>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> >>>>         
> >
> >   
> 
> 
> 
> 
> ------------------------------
> 
> Message: 18
> Date: Sun, 11 Oct 2009 19:15:01 +0200
> From: Kern Sibbald <kern AT sibbald DOT com>
> Subject: Re: [Bacula-users] [Bacula-devel] VirtualFull backup: bacula
>       selects the wrong read device
> To: Nicolae Mihalache <mache AT abcpages DOT com>
> Cc: bacula-devel AT lists.sourceforge DOT net,
>       bacula-users AT lists.sourceforge DOT net
> Message-ID: <200910111915.01664.kern AT sibbald DOT com>
> Content-Type: text/plain;  charset="utf-8"
> 
> On Sunday 11 October 2009 18:32:12 Nicolae Mihalache wrote:
> > Hello, I can only test tomorrow because now I have some long running
> > backups.
> 
> OK, no problem.
> 
> >
> > But isn't your change affecting the jcr->dcr which is the writing
> device?
> 
> I think that is the point.  jcr->dcr (should really be named
> jcr->write_dcr)  
> should not be changed when switching the read device, and I think my
> change 
> corrects that problem.
> 
> >
> > Have you tried running a virtual full or just a restore?
> 
> I ran both VirtualFull and restore jobs (the whole regression suite), but
> for 
> the VirtualFull, we do not currently have any regression tests that
> require 
> switching drives, which is why I would like to know if my fix works with
> your 
> specific problem.  
> 
> > I guess for a 
> > restore it is working because no writing device is being used.
> 
> Yes, that is exactly it.  During a restore, the jcr->dcr is not used, so
> if it 
> is "destroyed" (well changed) there is really no problem.  During a 
> VirtualFull, Migration, or Copy, changing jcr->dcr will create problems, 
> which is what I believe you are seeing.
> 
> By the way, the new_dcr(), form me is OK as is.  It does indeed create a
> new 
> dcr, but if it is possible to reuse the existing one, it does rather than 
> mallocing a new one.  In any case, any change to new_dcr() is a bit more 
> disruptive than I would like to do just now.
> 
> Best regards,
> 
> Kern
> 
> >
> >
> > nicolae
> >
> > Kern Sibbald wrote:
> > > Hello,
> > >
> > > That is *very* interesting.  Thanks for looking into this.  I think
> the
> > > code has previously worked for us because we may not have explicitly
> > > tested Migration and VirtualFull, but for restores it all works fine.
> > >
> > > Could you try one change to your fix?  Remove your fix, then change
> line
> > >
> > > reserve.c:637 from:
> > >
> > >    rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > > rctx.device->dev);
> > >
> > > to
> > >
> > >    dcr = new_dcr(rctx.jcr, rctx.jcr->dcr, rctx.device->dev);
> > >
> > > I think this will solve the problem in a slightly cleaner way.
> > >
> > > If the above works, I'll be happy to integrate it and get it out in
> 3.0.3
> > >
> > > Best regards,
> > >
> > > Kern
> > >
> > > On Sunday 11 October 2009 12:56:05 Nicolae Mihalache wrote:
> > >> I investigated a little more and found that if I replace the line
> > >>
> > >>     rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > >> rctx.device->dev);
> > >>
> > >> with
> > >>    if (rctx.store->append == SD_READ) {
> > >>       rctx.jcr->read_dcr = dcr = new_dcr(rctx.jcr,
> rctx.jcr->read_dcr,
> > >> rctx.device->dev);
> > >>    } else {
> > >>       rctx.jcr->dcr = dcr = new_dcr(rctx.jcr, rctx.jcr->dcr,
> > >> rctx.device->dev);
> > >>    }
> > >>
> > >> in reserve.c:637, it will work ok.
> > >> I was confused by the function new_dcr which despite its name,
> doesn't
> > >> create a new dcr if it already exists ( I think the name should be
> > >> changed).
> > >>
> > >> nicolae
> > >>
> > >> Kern Sibbald wrote:
> > >>> On Friday 09 October 2009 15:06:36 Nicolae Mihalache wrote:
> > >>>> Sorry, I'm not quite sure I grasp your message.
> > >>>> When you refer to Storage in "Changing Storage for restore and
> > >>>> migration", you talk about Storage Daemon or the Storage resource
> in
> > >>>> the director?
> > >>>
> > >>> I was not very precise.  I meant that changing Storage daemons is
> not
> > >>> supported in any released version.  Changing storage devices is also
> > >>> not officially supported in any released version, but there is code
> > >>> that seems to work in most cases.
> > >>>
> > >>>> I have one Storage Daemon with three different devices and three
> > >>>> corresponding storage resources in the director. What I want to do
> is
> > >>>> to read from two of those devices and write into the third one.
> > >>>> Changing between the two reading ones is not working. I did a bit
> of
> > >>>> debugging, and I found that:
> > >>>>
> > >>>> In stored/acquire.c
> > >>>>
> > >>>>       stat = search_res_for_device(rctx);
> > >>>>       release_reserve_messages(jcr);         /* release queued
> > >>>> messages */ unlock_reservations();
> > >>>>
> > >>>>       if (stat == 1) {
> > >>>>          dev = dcr->dev;                     /* get new device
> pointer
> > >>>> */
> > >>>>
> > >>>> In stored/reserve.c:
> > >>>>
> > >>>>  ok = reserve_device_for_read(dcr);
> > >>>>       if (ok) {
> > >>>>          rctx.jcr->read_dcr = dcr;
> > >>>>
> > >>>>
> > >>>> So basically the jcr->read_dcr is changed to point to a brand new
> dcr
> > >>>> in reserve.c but the code in acquire.c is using the old dcr. Also
> in
> > >>>> acquire.c there is a comment that says dcr pointer shouldn't
> change.
> > >>>
> > >>> If indeed the code in reserve.c is setting an entirely new dcr
> pointer,
> > >>> then it is unlikely the code will work.  So that may be the problem
> you
> > >>> are running into.  However, in all our tests, it does seem to work
> > >>> providing you have different MediaTypes for each device. Though as I
> > >>> say, it is not officially supported, simply because I don't have
> enough
> > >>> confidence in the code. If you have the same MediaType for different
> > >>> devices, then switching devices won't work.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Kern
> > >>>
> > >>>> nicolae
> > >>>>
> > >>>> Kern Sibbald wrote:
> > >>>>> Hello,
> > >>>>>
> > >>>>> You are attempting to use a feature that is not implemented.
> > >>>>>
> > >>>>> Changing Storage for restore and migration is not implemented in
> any
> > >>>>> released version of Bacula.
> > >>>>>
> > >>>>> Changing of Storage for restore is implemented in 3.1.x (not yet
> > >>>>> released). However, it is unlikely that it works for migration.
> > >>>>>
> > >>>>> Changing of devices within a given Storage should be implemented,
> for
> > >>>>> reading of any kind, but we do not guarantee that it works -- in
> your
> > >>>>> email, you did not specify much information so I cannot be more
> > >>>>> specific.
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> Kern
> > >>>>>
> > >>>>> On Friday 09 October 2009 12:37:50 Nicolae Mihalache wrote:
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> I run Full backups on MediaType=LOT-4 and Incremental backups on
> > >>>>>> MediaType=File. When running a VirtualFull into a tmp pool
> > >>>>>> (MediaType=TmpFile), bacula starts correctly reading the full
> backup
> > >>>>>> from LTO-4. However, when the Incremental starts, it still wants
> to
> > >>>>>> use the LTO-4 device instead of switching to the file device:
> > >>>>>>
> > >>>>>> 09-Oct 11:43 bacula-sd JobId 8889: End of Volume at file 46 on
> > >>>>>> device "HP" (/dev/st0), Volume "GROUPS-01" 09-Oct 11:44 bacula-sd
> > >>>>>> JobId 8889: acquire.c:116 Changing read device. Want Media
> > >>>>>> Type="File"
> > >>>>>> have="LTO-4" device="HP" (/dev/st0) 09-Oct 11:44 bacula-sd JobId
> > >>>>>> 8889: Media Type change.  New read device "HP" (/dev/st0) chosen.
> > >>>>>> 09-Oct 11:44 bacula-sd JobId 8889: Invalid slot=0 defined in
> catalog
> > >>>>>> for Volume "aa-work-0125" on "HP" (/dev/st0). Manual load may be
> > >>>>>> required.
> > >>>>>>
> > >>>>>> >From these logs it seems it wants to change the read device but
> for
> > >>>>>>>
> > >>>>>>> some
> > >>>>>>
> > >>>>>> reason selects the same (wrong) one.
> > >>>>>>
> > >>>>>>
> > >>>>>> Thanks for any hints.
> > >>>>>> nicolae
> > >>>>
> > >>>>
> ----------------------------------------------------------------------
> > >>>>-- --- --- Come build with us! The BlackBerry(R) Developer
> Conference
> > >>>> in SF, CA is the only developer event you need to attend this year.
> > >>>> Jumpstart your developing skills, take BlackBerry mobile
> applications
> > >>>> to market and stay ahead of the curve. Join us from November 9 -
> 12,
> > >>>> 2009. Register now! http://p.sf.net/sfu/devconference
> > >>>> _______________________________________________
> > >>>> Bacula-devel mailing list
> > >>>> Bacula-devel AT lists.sourceforge DOT net
> > >>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> 
> 
> 
> 
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> 
> ------------------------------
> 
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> 
> 
> End of Bacula-users Digest, Vol 42, Issue 10
> ********************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
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>
  • Re: [Bacula-users] Bacula-users Digest, Vol 42, Issue 10, Ulrich Schaefer <=