[Stgt-devel] Thoughts on vtl setup
Ming Zhang
blackmagic02881
Fri Apr 6 02:58:08 CEST 2007
On Fri, 2007-04-06 at 10:52 +1000, Mark Harvey wrote:
> 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'
tgtadm will pass tid, lun, op, and param to daemon, and then look up
target, its lu, and parse the parameter to that lun.
>
> When initially setting up the configuration, /dev/null is passed as
> the default backing file.
>
not bad.
>
> >
> >
> > >
> > > >
> > > > 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