[Stgt-devel] Thoughts on vtl setup
Mark Harvey
markh794
Fri Apr 6 02:52:56 CEST 2007
On 4/6/07, Ming Zhang <blackmagic02881 at gmail.com> wrote:
> 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?
I was thinking along the lines of a file name only. i.e. the library
will exec a "tgtadm --tid --lun --op load -b filename...." command to
the virtual SSC/SDC/MMC device.
If the information within the robot 'drive number 1' contains the TID
& LUN, then there will be enough information to build this command and
pass the virtual media ID filename as the '-b backing file'
When initially setting up the configuration, /dev/null is passed as
the default backing file.
>
>
> >
> > >
> > > 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