[Stgt-devel] Thoughts on vtl setup

[Ming Zhang]

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