[snip] > > I do not limit drive type x to read virtual media type y. > i.e. A drive configured as a SONY SDX-900V (AIT) can quite happily > read/write media created by a SDLT600 virtual drive. Extra checking of > the MAM data could limit this if required. But I can't see any real > benefit to this. Apart from a admin being able to determine the media > type by the file name. A small utility can quite easily read the MAM > information and print out the relevant data. Don't you just hate it when you post something, then re-read it just to find it makes no sense :( I do not limit a drive type to read/write media type. i.e. All virtual media is compatible with any type of virtual device. It would be extreamly easy to add checks when opening the virtual media file for a correct MAM type. But I can't see where this would not acheive anything useful. If anybody can come up with a semi-valid reason, I will add the check(s). > Tapes - Well, virtual tapes. I guess the filename can be the barcode, the extension the tape type, e.g. A00001.LTO2. However, when these files are accidentally renamed you loose the barcode and type. So every tape should have a header containing the barcode, and tape type. The barcode and tapetype should be in clear text (e.g. 4 characters LTO2). Another addition could be a two-byte field, containing bitfields, like this: > > 0000 0000 0000 RCCC > > were > CCC -> compression 0-7, where 0 is no compression, 1 is LZ, etc. for different types of compression, if implemented. We can start without compression. > > R -> Readonly bit, even if the file was readonly and set to readwrite, it would protect the data. Don't know if this setting can be done in the SCSI set. Apart from a admin being able to determine the media type by the file name I can see no useful advantage of this. A small utility can quite easily read the MAM information and print out the relevant data. There is a field in the MAM for 'Medium Serial Number'. When creating the virtual media, I set this with 'barcode_<ctime>' Each 'block' of data written has a header which contains the following fields to describe the block of data: Block Type -> End of data, Beginning of data, file mark, data block etc. Block Size -> Size of raw data (uncompressed data size) Disk Block Size -> Size of data to be read/written from/to file. Or another way of putting it: how much data to skip to fine the next data block header. The BLOCK TYPE field could be expaneded to specify the compression type used, however it has always been my intention to use the zlib compression library routines. It has never made it into any actual code. > [snip] |