Bacula-users

Re: [Bacula-users] Storage to storage feature in 7.0.x

2014-05-22 11:32:27
Subject: Re: [Bacula-users] Storage to storage feature in 7.0.x
From: Kern Sibbald <kern AT sibbald DOT com>
To: Josip Deanovic <djosip+news AT linuxpages DOT net>, bacula-users AT lists.sourceforge DOT net, waa-bacula AT revpol DOT com
Date: Thu, 22 May 2014 17:28:55 +0200
Hello Josip,

I have pushed a patch from Eric, that I believe fixes your bug.  It is
in the current public git repo, and I would appreciate it if you would
test it.

Hello Bill,

I have also pushed a patch that may well fix the problem you are having
with cancel.  I have never been able to reproduce the problem, but I did
yet another rewrite of the sellist routine as well as designed a number
of tests, none of which every failed.  However, in the process I noticed
that the source code that called the sellist methods was using the wrong
calling sequence (my own fault).  I am pretty sure that is what was
causing your problem.  In any case, this new code is in the current git
public repo and I would appreciate it if you would test it.

Best regards,
Kern

On 05/21/2014 10:53 AM, Josip Deanovic wrote:
> Josip DeanovicOn Tuesday 2014-05-20 23:04:14  wrote:
>> On Tuesday 2014-05-20 19:04:15 Kern Sibbald wrote:
>>> I did hundreds of copy/migration jobs testing this new feature.  I
>>> only
>>> did a few with a totally separate SD though.
>> I'll make additional tests tomorrow and report here with more info.
> I have performed few more tests using setup as described below.
>
> # Case 1
> - single server
> - single storage daemon
> - two devices
> - two media types
> - two storage resource definitions in the director configuration, each
>   pointing to it's own device and media type
> - two pools, each pointing to it's own storage definition
> - single copy job configured to select single, last full successful
>   regular job
>
> The result of Case 1: everything works as expected and the regular job
> has been copied from one device to another device configured in the
> same storage daemon.
>
>
> # Case 2
> - single server
> - two storage daemons, the additional SD is listening on the port 9113
> - two devices
> - two media types
> - two storage resource definitions in the director configuration, each
>   pointing to it's own device and media type and SD port
> - two pools, each pointing to it's own storage definition
> - single copy job configured to select single, last full successful
>   regular job
>
> The result of Case 2: it fails the same way as I reported to be the
> case with the SD places on the remote server.
>
>
> Kern, could you please test the "Case 2" yourself and confirm that it
> actually works? I am now even more convinced that it is not the case
> of misconfiguration on my part.
>
>
> Kind regards
>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users