This will sound like a "oh, not this topic AGAIN" sort of question, but.... :-)
Would it be terribly difficult to let me specify a separate path/directory per virtual tape?
I know this sounds like an odd request, but let me explain why. SGI sells some archival storage called MAID storage (http://www.sgi.com/products/storage/maid/). On this storage, most of the drives are powered off most of the time, allowing us to cram more storage in a single footprint. And the drives are spun up on demand. Each shelf has 26 LUNs, some configurable portion of which is in a 27th "always on region" (usually containing things like disk/filesystem labels, etc). And only a certain number of LUNs (also configurable) can be powered on at any given time.
So one obvious solution (already discussed) would be to just make a whole bunch of symbolic links in /opt/mhvtl the pointed to these MAID LUNs (I've currently got them setup with the auto-mounter so most of them will be unmounted most of the time). The problem with this is that when tools run that scan all the local filesystems hit these links, they power on each LUN, one by one, and access it (like the updatedb program). If I auto-mount these LUNs, say with a path like /maid/shelf-3-lunXX, programs like updatedb don't access them causing them to spin up - except for when someone makes a link pointing to them.
Any chance? I've done a bit of C in my past. I might even take a crack at it myself if someone would just point me in the right direction.
Failing that, if it's safe to assume nothing will be in /opt/mhvtl except for virtual tapes, I might just allocate an entire shelf (or more) to mhvtl and then have /opt/mhvtl/<volume-name> be the auto-mounted LUNs...
Re: possibility to specify per-tape path or homedir
There is a setting for each library to change the default path for all media within the library:
Home directory: /opt/mhvtl
The 'hard' bit from what I can see would be 'how' & 'where' do you define the path for each media ?
Each 'library' would need to be able to locate each media..
Moving to an xml format to describe each attribute would be one method..
There was an attempt a couple of years ago for xml config (0.19 was the branch version) but that caused all sorts of compatibility issues with nia and the web gui front end.
Basically, there were other 'more interesting' features that needed to be developed and xml was placed in the too much effort basket.
Another advantage of 'xml' would be each media could be 'pre-defined' (type, size, etc) and there would be no need for the horrible hack of a script of 'make_vtl_media'. If the media did not exist on a mount request the library could create the media first (as there would be enough info in the media xml to describe all it's parameters).
Multiple partition support is next on my to-do list, so it's not something that would be just around the corner from a code/feature point of view..
Re: possibility to specify per-tape path or homedir
I've made "figuring out where the media is" the auto-mounter's problem. Basically, I'm formatting the LUNs with a filesystem label name and then when I access /maid/<filesystem-label> it executes a mount command with a -L option. Since the filesystem labels are in the "always on region" on the MAID, the automounter can quickly find which device contains which filesystem or if there is none that matches that without having to spool devices up 'n down. :-)
So... I did figure out a work-around that appears to work. I just had to reformat all the LUNs with the filesystem labels matching the tape labels that mhvtl will expect to use. Then I tweaked the automounter to use the path of the home-directory for that VTL, so when mhvtl tries to use tape labeled "whatever" the automounter will dutifully mount it - /opt/mhvtl/vtl-name/tape-label is now automounted from the MAID storage. :-) It means I wouldn't be able to use the shelfX-lunAB naming convention I've been using, but that's not a huge issue (or I don't think it will be) since I can make the tape labeling scheme include a shelf number and lun number.
I tested it in a VM and it worked fine, so it *should* work equally well with the real MAID hardware. :-) Now I just need to retire and re-format another shelf for testing it on the real hardware. :-)
The only trouble I ran into is when MHVTL tries accessing every virtual tape rapidly, one at a time (say, like when I'm first creating all the tapes or when I have backup software writes a label to every tape). I'm not 100% positive, but I *think* this might be the automounter getting fouled up. I wind up with lots of LUNs mounted, most of which I'm done with but just haven't been unmounted from an idle timeout yet. And I suspect that then the automounter has issues when the unmount takes a long time because a newly spun up LUN has to be spun down so the one being unmounted can be spun back up and unmounted (unmounting writes a little bit to the LUN). I'll have to see if it's possible to make a better "always-on-region" to cover mounting and unmounting, in which case I'd no longer need the automounter.
Or an alternative would be just having the option to tell mhvtl to execute a command just before mounting a tape or just after unmounting one. Something for the feature wish list? :-)