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
------------------------------------------------------------------------------
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
|
