Hi.
> In a normal Bacula Storage daemon, you probably would never have more than
10
> devices total (some very large installations may be the exception).
> Consequently, I cannot see the utility of this request.
Yes, I know I can create a separate device for every job I want to run
independently of others. But in HDD-based backups it just doesn't make any
sense. I have explained the limitation and workarounds to administrators who
are not familiar with Bacula at all and explaining this really sounds very
obscure and creates bemusement.
> If you are using more than 10 devices in a Storage daemon, you are probably
> doing something wrong.
Or it means I have more than 10 jobs I want to be running concurrently.
> Implementing this feature, as I understand it, would
> create a number of problems such as making it impossible to do things like
> mount and unmount of volumes
Is there really any need for (un)mounting volumes in HDD-based environment?
What does it mean in that case?
> or labeling them, because within the current
> Bacula structure you need a unique device name.
Do you mean re-labelling? If so, then I cannot say anything about it, because
I haven't needed it in my tens and tens of backup-servers during the last 4
years.
Although I don't know how devices are handled in Bacula, there are actually
even more configuration parameters that are not needed for HDD-based devices.
Maybe it would make sense to write a very simple disk-based device handler
that would lack the complexity (if there is any) of the one handling tape
drives? Just a question..
> There are at least three different ways to conveniently read/write to
multiple
> Volumes:
> 1. Use multiple separately defined SD Devices
> 2. Use multiple Devices controled by a disk autochanger script (there are
> several of these scripts available, including one from the project).
> 3. Use a Bacula Virtual Disk Autochanger where no autochanger script is
> needed.
>
> All the above methods work well and many *very* large sites use these
> techniques.
Yes, I'm not saying it cannot be done, but rather that it can be done in
better way. These 3 methods are just workarounds of the configuration
limitations, aren't they? Would there be any point for them if multiple
volumes could be written concurrently within a device?
> In addition, one should take care in using multipe disk Devices that write
to
> the same physical disk drive. Depending how you set it up and how many you
> have, you may create severe disk fragmentation and performance problems.
System administrators can break things in many ways, but I don't see how it's
relevant to being able to configure server in any way. For an instance, I can
define really stupid retention times for my pools, but it doesn't mean I
shouldn't be able to configure them.
> Bottom line:
> This feature request would add no new functionality, and Bacula already has
> quite adequate means to do what you want to do. So I am sorry, this feature
> is not something that we will implement.
Yes, no new functionality. It would just make possible some very-very trivial
configuration.
--
Silver
> On Sunday 28 March 2010 19:00:06 Silver Salonen wrote:
> > It seems this message hasn't made it to bacula-devel, so I'm sending it
> > again..
> >
> >
> > Item: Allow writing to multiple volumes concurrently on file-type
> > devices
> > Origin: Silver Salonen (silver AT ultrasoft DOT ee)
> > Date: 15.Mar.2010
> > Status:
> >
> > What: Currently Bacula allows only one volume to be written per
device. For
> > file-type devices (eg. HDD) it would make sense to allow writing multiple
> > files/volumes concurrently.
> >
> > Why: For file-type devices it makes the most sense (at least to me)
> > to use
> > one job per volume (file) to get the best overview of the existing jobs,
to
> > rotate them and manage them in any other way. When using this type of
> > configuration, currently one needs as many Bacula devices as many jobs one
> > wishes to run concurrently. Or virtual changer has to be used. Allowing
> > writing multiple volumes concurrently would let the configuration be
> > simpler and more optimized.
> >
> > Notes: For backwards-compatibility it would make sense to add a new
option
> > for the limit (eg. "Maximum concurrent volumes"?) and set it to 1 by
> > default. The limit would also need "Random Access = yes".
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
