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 (sil...@ultrasoft.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-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
