[Stgt-devel] Thoughts on vtl setup

[Mark Harvey]

[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]