Thanks a lot, I will switch to version 3.0.3 as soon as it is out.
In the meanwhile I was running with the my modification and so far
didn't have any trouble (but I'm not using bextract).
nicolae
Kern Sibbald wrote:
> Hello,
>
> On Monday 12 October 2009 04:09:16 Nicolae Mihalache wrote:
>
>> I tried your change but VirtualFull with multiple read devices is not
>> working. Restore is working but it was working even without your change.
>>
>
> Yes, I hadn't noticed one small important detail in your code :-( so my code
> didn't implement what you had done.
>
>
>> I think I know why:
>> 1. the code from reserve.c:637
>>
>> dcr = new_dcr(rctx.jcr, rctx.jcr->dcr, rctx.device->dev);
>>
>> always changes the write device, never the read device. The function
>> new_dcr returns the rctx.jcr->dcr if it's not NULL. Your change of
>> removing the "rctx.jcr->dcr=" in front has no effect when the dcr is
>> not NULL.
>> 2. however, further down in reserve.c:716
>>
>> rctx.jcr->read_dcr = dcr;
>>
>> this makes effectively the read_dcr the same with the write dcr. The old
>> read_dcr is lost.
>> 3. why restoring from multiple devices works? Because after the first
>> pass, the read_dcr and the write dcr are the same, so in all the
>> subsequent passes, changing the write dcr will also change the read_dcr.
>> In restores the write dcr is not used so it all works.
>> 4. why the virtual full backup works when there is only one read device?
>> Because the storage director selects first the read dcr (overwriting in
>> the same time the write dcr) but then it creates a brand new write dcr
>> in reserve.c:251. So the original write dcr is used for reading and a
>> new dcr is used for writing. This all happens before the backup starts
>> when the dcr pointers can still change (apparently).
>> 5. why the virtual full backup doesn't work when there is more than one
>> device? Because the trick of transforming the write dcr into the
>> read_dcr doesn't work anymore first because the backup has started and
>> dcr pointers can't change anymore and second because the write dcr is
>> still needed.
>>
>
> OK. I have reviewed the code again, and put in your code but re-written
> slightly. The only problem is that it then breaks bextract. After a good
> deal of debugging, I finally figured out why (a problem of initialization of
> read_dcr I think). It is now fixed and in version 3.0.3.
>
>
>> nicolae
>>
>> Kern Sibbald wrote:
>>
>>> 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.
>>>
>> The name new_dcr is confusing (not anymore to me). The function returns
>> the dcr passed as argument unless it was null. It should be perhaps
>> called "renew_dcr". Maybe I'm spoiled by all these OOP languages where
>> new of something makes you a brand new object.
>>
>
> I have attached the patch that went into version 3.0.3 (applies in principle
> to 3.0.2 on top of my previous (broken) patch. You will see that the code in
> reserve.c is essentially identical to yours, and there is one new line added
> to acquire.c (jcr->read_dcr = dcr;) that is important if you want bextract
> to work.
>
> Version 3.0.3 should be released Monday at the latest ...
>
> Thanks for your work on this. It was extremely helpful.
>
> Best regards,
>
> Kern
>
------------------------------------------------------------------------------
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
|
