[Stgt-devel] Thoughts on vtl setup
Ming Zhang
blackmagic02881
Fri Apr 6 02:34:58 CEST 2007
On Fri, 2007-04-06 at 09:20 +1000, Mark Harvey wrote:
> 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.
>
yes, this MAM is the metadata we meant. what i meant is to give MAM a
version so we can expand it later.
if i have a tape i try to switch the readonly and read/write, i need an
extra utility before i put into tape drive.
tape drive need to check MAM for some capability.
>
>
> >
> > 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.
>
this is what i want. but can media id be a file id or file name?
>
> >
> > Albert
> >
> > _______________________________________________
> > Stgt-devel mailing list
> > Stgt-devel at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/stgt-devel
> >
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel
More information about the stgt
mailing list