First off - Many thanks for the offer of help.. Always most welcome.
I have started to look at adding multi-partition support with the goal of LTFS support (started back in March)..
Due to paid work commitments, the amount of spare time I've been able to put into this has been almost zero.
My initial thoughts were to create a new on-disk file format:
/opt/mhvtl/<barcode>/xxxx.mam -> Contains MAM structure only.
/opt/mhvtl/<barcode>/xxxx.meta_N -> metadata & filemark data for partition N
/opt/mhvtl/<barcode>/xxxx.data_N -> Raw data content for partition N
/opt/mhvtl/<barcode>/xxxx.indx_N -> Index data for raw datafile _N
Currently MAM and meta data is in one file (.meta).
I've got code to do this, however no conversion of current to new format tools at this point.
The other option is to not split out the MAM and meta file and "waste" the 1.5k or so of MAM space on .meta_N for subsequent partition files (Advantage is backward compatibility)..
I'm more than happy to share what I've got and provide any input as appropriate..
The real tape drives I have available do not support multi-partition, so this is also a head-ache. Being able to query a real drive to confirm my understanding of the specifications is always nice.
I probably asking something obvious here.
I understand the value of using a VTL, also the value of using LTFS and physical tape but what is the benefit of LTFS in a VTL environment ? What i mean is that disk is used to emulate tape over which we now write data using the LTFS file system. So why not just write to disk over a file system ? I know of another open source implementation with LTFS support, but i fail to understand why the additional complexity :-)
Exactly the same arguments can be used against Virtual Tape Libraries..
In modern day backup environments, VTLs are un-needed and just complicate things.
Why convert perfectly good random access device into pseudo sequential access ?
10 Years ago, when backup software only knew one type of destination (tape), they made some sense..
Any respectable backup software now days utilise disk in a variety of useful fashions (dedupe, spaning backups across multiple disks/file systems, not interleave multiple streams of backup data into a single sequential stream.. etc)
The design goal of mhVTL was to emulate real tape library in order to support/learn/demo how backup applications work with real tape libraries. Hence mhVTL has the concept of cleaning media, WORM media, TapeAlert flags, Media Access Ports etc.. Things that really don't make any sense for Virtual Tape Libraries.
Hence the addition of LTFS will allow the same type of audience to test/experiment/learn/demo without the need for $$$$ and bulky hardware.
From a personal point of view - I have no real use for LTFS. I do not have any real hardware setup to be able to use to start developing.. Attempting to develop something from the t10.org documentation is a little outside my definition of 'fun'.
There are so many things still to do to the code base in relation to make mhVTL behave like real devices do that LTFS keeps getting pushed down that magical todo list - but is hovering on the 'lets get this done' border line..