[Stgt-devel] Thoughts on vtl setup

[Albert Pauw]

Hi Ming,

Ming Zhang wrote:
> On Thu, 2007-04-05 at 21:32 +0200, Albert Pauw wrote:
>> Here are a few thoughts I wanted to share regarding the virtual tape
>> library, just shoot at it if you think otherwise. Hope you don't find
>> this too nosy Mark (Harvey) as you started the idea.
>>
>> General - Best would be to have the changer and the tapedrives on one
>> target, the changer can be LUN 0, the drive(s) LUN 1 and onwards.
>
> in real world, tape and changer most time does not use 1 target. though
> some of them are. so ideally is to have both.
>
> of course, for simplicity purpose, i agree with u. but since it is
> emulation, it should looks like real stuff.
>
Maybe have  it standard set to one target, unless you define otherwise?
>> Configuration - Would be best to keep this simple. The changer can be
>> a standard one, implementing all necessary functions. For the drives
>> you define the type once, and how many drives you want. If you use
>> symbolic names (as to numeric) for the drive types, then this can be
>> easily expanded. E.g. LTO3, DDS4, etc. for the drive type. If you need
>> three different type of drives, then you just add one of each type.
>> Since these types are predefined you don't have to set other
>> parameters for these drives (like size etc). Lastly you define the
>> directory where the tapeslots are.
>
> problem is different real changer will not always perform the same and
> some have features others do not have. so no one emulation fit all
> solution.
>
> ideal way is the code implement as many feature sets as possible. and
> specific model can enable/disable or override the generic
> implementation.
>
Sounds the way to go!
>
>> 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
>
> yes. need a header or extra meta file to describe the tapes.
A header is probably better, you can not loose it from the tape.
>
>> 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.
>
> virtual tape drive can read this and disable write. 
That was the idea.
>
>> Tape handling - Before starting stgt vtl and point it to the tapeslot
>> directory you create tape slot subdirectories like this, where you
>> define at startup the directory /var/tape as the slot directory:
>>
>> /var/tape/slot-01
>> ...
>> /var/tape/slot-24
>>
>> In the /var/tape directory there would be symbolic links like this
>>
>> /var/tape/drive-1 -> /var/slot-01/A00001.LTO3
>>
>> if a tape is loaded into drive-1, when a drive is empty (startup
>> setting) it does not have a symbolic link.
>>
>> Note that by creating these directories by hand you can define how
>> many slots you have, but also leave existing "tapes" in the slots
>> between restarts of the vtl stgt service. And stopping the service
>> should delete the symbolic drive links, so the drives "eject" the
>> virtual tape and start up "empty" next time.
>
> this sounds interesting. but what is the action to "insert" a tape to
> drive? then program has to capture the symlink event.
>
Maybe define something like a mailslot? You can just move it to the proper slot, or have
it put in a free slot, just like a real StorageTek L700. A sort of CAB directory where you can put in
one or more tapes. When you "close" the CAB, it starts scanning the tapes.