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