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