On Thu, 2007-04-05 at 21:53 +0200, Albert Pauw wrote: > Hi Ming, > > Ming Zhang wrote: > > On Thu, 2007-04-05 at 21:32 +0200, Albert Pauw 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. > >> > >> 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. > > > > in real world, tape and changer most time does not use 1 target. though > > some of them are. so ideally is to have both. > > > > of course, for simplicity purpose, i agree with u. but since it is > > emulation, it should looks like real stuff. > > > Maybe have it standard set to one target, unless you define otherwise? suggestion, pls add one blank line before and after u reply so people can find it easier. thanks. not sure. Mark is the workhorse so he decide. ;) > >> 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. > > > > problem is different real changer will not always perform the same and > > some have features others do not have. so no one emulation fit all > > solution. > > > > ideal way is the code implement as many feature sets as possible. and > > specific model can enable/disable or override the generic > > implementation. > > > Sounds the way to go! > > > >> 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 > > > > yes. need a header or extra meta file to describe the tapes. > A header is probably better, you can not loose it from the tape. fine. like preserve N KB for this purpose. header version header length ... file data ... so allow us to expand the header later if need. > > > >> 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. > > > > virtual tape drive can read this and disable write. > That was the idea. > > > >> 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. > > > > this sounds interesting. but what is the action to "insert" a tape to > > drive? then program has to capture the symlink event. > > > Maybe define something like a mailslot? You can just move it to the proper slot, or have > it put in a free slot, just like a real StorageTek L700. A sort of CAB directory where you can put in > one or more tapes. When you "close" the CAB, it starts scanning the tapes. > why not a tgtadm ... --cmd load/unload <drive> <tape>? > > _______________________________________________ > Stgt-devel mailing list > Stgt-devel at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/stgt-devel |