[Stgt-devel] Thoughts on vtl setup

[Mark Harvey]

On 4/6/07, Albert Pauw <pauw at o2.ie> 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.
>
Please chip in with any ideas / suggestions.

I'm looking at this from one angle. Other perspectives most welcome.


> 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.
>

I can see no real benefit in limiting the vtl to fit this model.

My current implementation of a vtl (based on the scsi_debug linux
module and some user-space daemons) does in deed work this way. I have
the kernel module hard-coded so LUN 0 is reported as type 8, and all
other LUNs are type 1.

I ideally would like to be able to configure multiple changers with
SSC, SBC or MMC devices.

So the current 'limitation' of having one TID being tied to one device
type is not a limitation IMO.


> 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.
>

> 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.


Based on experience with my current vtl, this is generating a lot of
work for little to no gain.

I have a 'MAM' structure (fields pinched from IBM Ultrium
documentation) at the start of the virtual media. Within this
structure is information about the media type (WORM, cleaning, data,
media capacity).

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.



>
> 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.
>
> Well, just a thought.

Again, this is based on experience with my current vtl implementation.


All 'movement' of media within the library (between slots and between
drives) are performed in core. No modification to any configuration
files exist.

I have a data structure for each slot and one field indicates if it
contains media. A move just sets/resets this bit + barcode of media in
the slot.

Setting up the linked list structures will be done at configuration
time using the following (proposed) syntax of:
The README.vtl has an example of a complete configuration setup.
       ==============================
=== Allocate 1 picker at address 256...
tgtadm --lld iscsi --mode logicalunit --op update --tid=2 --lun=0 \
        -n ElementType -v 1     \
        -n StartAddress -v 256  \
        -n Quanity -v 1         \
        -n Sides -v 2

=== Allocate 800 slots starting at address 1024
tgtadm --lld iscsi --mode logicalunit --op update --tid=2 --lun=0 \
        -n ElementType -v 2     \
        -n StartAddress -v 1024 \
        -n Quanity -v 800       \
        -n Sides -v 2

=== Allocate 10 Import/Export slots starting at address 128
tgtadm --lld iscsi --mode logicalunit --op update --tid=2 --lun=0 \
        -n ElementType -v 3     \
        -n StartAddress -v 128  \
        -n Quanity -v 10        \
        -n Sides -v 2

=== Allocate room for 8 drives
tgtadm --lld iscsi --mode logicalunit --op update --tid=2 --lun=0 \
        -n ElementType -v 4     \
        -n StartAddress -v 1    \
        -n Quanity -v 8         \
        -n Sides -v 1
       ==============================


I plan on sending a 'tgtcmd --tid --lun --op load -b <media ID>' type
command to signal a virtual drive that the media has been placed into
it. The virtual drive will then open the <media ID> as a file handle
(backing file)' for any read/write/positioning.


>
> Albert
>
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel
>