On Tuesday 23 February 2010 20:45:26 Martin Simmons wrote:
I think you have the concept backwards -- it is designed to prevent
concurrency on that device rather than allowing more of it.
The default allows an unlimited number of jobs to be queued (or run
concurrently on a single volume).
On Tuesday 23 February 2010 19:09:49 Phil Stracchino wrote:
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any opinions?
I ran into this problem when I first upgraded to 3.0.3. It turned out
to be a configuration issue. Make sure you have the
On Wed, 24 Feb 2010 11:58:22 +0200, Silver Salonen said:
On Tuesday 23 February 2010 20:45:26 Martin Simmons wrote:
I think you have the concept backwards -- it is designed to prevent
concurrency on that device rather than allowing more of it.
The default allows an unlimited number of
On Wednesday 24 February 2010 13:38:17 Martin Simmons wrote:
On Wed, 24 Feb 2010 11:58:22 +0200, Silver Salonen said:
No, the default for devices has always been to allow only 1 job.
That's not correct. Bacula has always been able to run multiple concurrent
jobs to the same device, as
On Tuesday 23 February 2010 19:09:49 Phil Stracchino wrote:
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any opinions?
I ran into this problem when I first upgraded to 3.0.3. It turned out
to be a configuration issue. Make sure you have the
On Wed, Feb 24, 2010 at 8:07 AM, Silver Salonen sil...@ultrasoft.ee wrote:
On Tuesday 23 February 2010 19:09:49 Phil Stracchino wrote:
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any opinions?
I ran into this problem when I first upgraded to
OK. I have never used tapes with Bacula. But I'd expect a file-type device to
be able to load more than 1 volume at a time. It's quite trivial, isn't it?
This was a design decision that all devices are treated the same way.
Anyway, the 1 volume at a time-limit has always been one job at a
On Wednesday 24 February 2010 15:34:27 John Drescher wrote:
On Wed, Feb 24, 2010 at 8:07 AM, Silver Salonen sil...@ultrasoft.ee wrote:
On Tuesday 23 February 2010 19:09:49 Phil Stracchino wrote:
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any
Are you saying that for concurrent jobs to work I have to run these different
jobs into the same volume? It doesn't make any sense in the means of disk-
based backups.
If they are not the same volume then you need to have more than 1
storage device. Remember that only 1 volume can be loaded
On Wednesday 24 February 2010 15:58:57 John Drescher wrote:
OK. I have never used tapes with Bacula. But I'd expect a file-type device
to
be able to load more than 1 volume at a time. It's quite trivial, isn't
it?
This was a design decision that all devices are treated the same way.
It's
On Wednesday 24 February 2010 16:42:50 John Drescher wrote:
On Wed, Feb 24, 2010 at 9:25 AM, Silver Salonen sil...@ultrasoft.ee wrote:
What's the use of treating all the devices the same way anyway? Ease of
programming? Even though it makes this part of the whole project so rigid?
Ease
On 2/24/2010 9:25 AM, Silver Salonen wrote:
On Wednesday 24 February 2010 15:58:57 John Drescher wrote:
OK. I have never used tapes with Bacula. But I'd expect a file-type device
to
be able to load more than 1 volume at a time. It's quite trivial, isn't
it?
On Wed, Feb 24, 2010 at 9:25 AM, Silver Salonen sil...@ultrasoft.ee wrote:
On Wednesday 24 February 2010 15:58:57 John Drescher wrote:
OK. I have never used tapes with Bacula. But I'd expect a file-type device
to
be able to load more than 1 volume at a time. It's quite trivial, isn't
it?
On Wednesday 24 February 2010 17:03:58 Josh Fisher wrote:
On 2/24/2010 9:25 AM, Silver Salonen wrote:
It's like assuming that the ultimate backup-devices are tapes. And as I
don't think that way, it's so annoying these design decisions rely on
somebody's (emotional/historical) opinion.
If volumes were files, there wouldn't be any need to limit them for devices
which would be directories in that context.
Again the limit is only 1 volume can be loaded in 1 storage device at
a time. This is not that big of a limitation because with disk you
can have 1 storage devices if
On 02/24/10 08:07, Silver Salonen wrote:
On Tuesday 23 February 2010 19:09:49 Phil Stracchino wrote:
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any opinions?
I ran into this problem when I first upgraded to 3.0.3. It turned out
to be a
On 02/24/10 08:07, Silver Salonen wrote:
BTW, this part is very obscure in the manual:
if you want two different jobs to run simultaneously backing up the same
Client to the same Storage device, they will run concurrently only if you
have
set Maximum Concurrent Jobs greater than one in the
On Wed, Feb 24, 2010 at 2:14 PM, Phil Stracchino ala...@metrocast.net wrote:
On 02/24/10 08:07, Silver Salonen wrote:
On Tuesday 23 February 2010 19:09:49 Phil Stracchino wrote:
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any opinions?
I ran into
On Wednesday 24 February 2010 19:28:05 John Drescher wrote:
If volumes were files, there wouldn't be any need to limit them for
devices
which would be directories in that context.
Again the limit is only 1 volume can be loaded in 1 storage device at
a time. This is not that big of a
I consider it a bug, but looks like devs do not. Any opinions?
http://bugs.bacula.org/view.php?id=1508
--
Silver
On Tuesday 16 February 2010 09:56:21 Silver Salonen wrote:
Hi.
In 5.0 there is directive Maximum Concurrent Jobs for devices too, which
should mean that it's now possible to
On 02/23/10 06:32, Silver Salonen wrote:
I consider it a bug, but looks like devs do not. Any opinions?
I ran into this problem when I first upgraded to 3.0.3. It turned out
to be a configuration issue. Make sure you have the desired level of
concurrency enabled in ALL applicable resources
I think you have the concept backwards -- it is designed to prevent
concurrency on that device rather than allowing more of it.
The default allows an unlimited number of jobs to be queued (or run
concurrently on a single volume). The new resource allows you to force jobs
to run on another
-Original Message-
From: Silver Salonen [mailto:sil...@ultrasoft.ee]
Sent: 16 February 2010 07:56
To: bacula-users@lists.sourceforge.net
Subject: [Bacula-users] concurrent jobs on the same storage
Hi.
In 5.0 there is directive Maximum Concurrent Jobs for devices too,
which should mean
-Original Message-
From: Silver Salonen [mailto:sil...@ultrasoft.ee]
Sent: 16 February 2010 07:56
To: bacula-users@lists.sourceforge.net
Subject: [Bacula-users] concurrent jobs on the same storage
Hi.
In 5.0 there is directive Maximum Concurrent Jobs for devices too,
which should mean
I suppose this is true. Sorry, I can't help then.
-Original Message-
From: Silver Salonen [mailto:sil...@ultrasoft.ee]
Sent: 16 February 2010 09:00
To: bacula-users@lists.sourceforge.net
Cc: Beck J Mr
Subject: Re: [Bacula-users] concurrent jobs on the same storage
I have set maximum
Hi.
In 5.0 there is directive Maximum Concurrent Jobs for devices too, which
should mean that it's now possible to run multiple jobs simultaneously on the
same device and therefore on the same storage. Right?
I have Maximum Concurrent Jobs = 20 set for SD, for 'storage-silver' and for
26 matches
Mail list logo
