On 04/03/2015 07:33 AM, Josh Fisher wrote: > Actually, I have been working on vchanger, and version 1.0.0 should be > released soon, hopefully in April or early May. > > While the LISTALL command is indeed implemented in mtx-changer and > disk-changer since Bacula version 5.1, it is not documented in the Bacula > Autochanger Interface documentation, or anywhere else to my knowledge. > > Since neither the Storage Daemon nor the Director use the LISTALL command, > the statement that vchanger will not work with any bacula > 5.1 is simply not > true. It just will not work with some of the web-based GUIs. My guess is that > one of the GUI projects added LISTALL to mtx-changer, but it was never > documented. Nevertheless, another user has already requested LISTALL support > and it is being added in vchanger 1.0.0.. > > New features for 1.0.0 will be: > > 1. Change in the way volume files are mapped to virtual slots and in the way > virtual drives are loaded. > ��� When vchanger began, Bacula supported Storage Daemon on Windows Server > 2003. Since that > ��� version of Windows could symlink to directories, but not to files, > symlinks had to be created to the > ��� magazine mountpoint and metadata stored on the magazine to track loaded > drives. Vchanger will > ��� now simply use symlinks as the virtual drive, the target of the symlink > being the volume file that is > ��� loaded in the virtual drive. This allows a number of nice features, > including: > ������� * Individual magazines can have any number of volume files > ������� * Volume files can have any filename > ������� * New volume files can be added or removed dynamically without config > file change > ������� * Volume files can be moved from one magazine to another without > affecting volume labeling > ������� * Volume files created for a native disk Device resource can be moved > to a magazine used > ���������� with a vchanger Autochanger resource as long as the Media Type > matches. > ������� * Dynamic and unlimited number of virtual drives without config file > change. The actual number > ���������� of Virtual drives used is determined only by the number of Device > resources defined in the > ���������� Storage Daemon config file. > 2. Now uses libudev, if available, to determine magazine filesystem > mountpoints by UUID > 3. Supports sending 'update slots' and 'label barcodes' commands via bconsole > as needed > 4. New udev rules generator supplies udev rules to send 'update slots' > command at udev hotplug > ��� event detection to support plug-n-play of external drives > 5. Added support for undocumented LISTALL command > 6. Deprecated INITMAG extended command > 7. Added CREATEVOLS extended command to support dynamic creation of volume > files > 8. Added REFRESH extended command to support udev hotplug events > 9. Added spec files for building RHEL6 and RHEL7 RPM s > 10. Updated documentation >
Wow. This is just great news. I was a bit hesitant to use vchanger in the beginning because the project seem to have been dropped. But in doing my research, vchanger was still the best solution to my problem at hand at switching out hard drive media. Let me echo what others have said and that your documentation is simply outstanding. Your documentation let me deploy vchanger in a relativity short time and I greatly appreciate it. Let me add, can you add a documentation item about "Media Type". I got bit by this configuration option. Media Type can be any string, but I thought it has to be a specific syntax like "File". I configured two vchanger configs. One for 3TB drives and one for 8TB drives. Since I had "File" for both Media Types, the 3TB vchanger would try and mount the 8TB vchanger volumes and vice versa. I ended up manually modifying the database itself in order to update the Media Type for those volumes that had already been labeled by Bareos. I know have two different Media Types, Vchanger_8TB_50GB_Volumes and Vchanger_3TB_50GB_Volumes. I planned on adding other vchanger configs when I use other drive capacities. Another nice addition to the documentation would be about planning out the disk capacity. I actually over subscribed my drives. I had set the option "Maximum Volume Bytes = 50G" set for my "Main_Pool" and I specified more volumes then what the drive could hold. It seems, that if vchanger runs completely out of space on that drive, the Magazine/Drive will no longer function at all. Some space needs to be manually freed up in order for vchanger to function again with that Magazine/Drive. So at that point I created two separate vchanger configs with the exact volume number specified at the size limit of 50GB for each volume. A note on calculating space. 1GB of volume space is 1,073,741,824 Bytes. These are the notes I added for figuring out how many 50GB volumes I could get on a 8TB drive. # The Main_Pool in bareos-dir.conf has "Maximum Volume Bytes" set to 50G. # 1 Gigabyte = 1,073,741,824 Bytes - 2^30 (1 MB = 2^20, 1TB = 2^40) # Web based calculator: http://www.whatsabyte.com/P1/byteconverter.htm # 50 Gigabytes = 53687091200 Bytes # Size of just formatted 8TB drive in MB = 7189021 (using df -m device) # Convert 7189021 MB to Bytes -> 7538234884096 # Slots = 7538234884096 / 53687091200 = 140.410566406 # 140 is the number of slots with approximate .4 volume of space left unused. Chris -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
