[Stgt-devel] Thoughts on vtl setup

[Ming Zhang]

On Fri, 2007-04-06 at 10:31 +1000, Mark Harvey wrote:
> [snip]
> >
> > 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.
> 
> Don't you just hate it when you post something, then re-read it just
> to find it makes no sense :(
> 
> I do not limit a drive type to read/write media type. i.e. All virtual
> media is compatible with any type of virtual device. It would be
> extreamly easy to add checks when opening the virtual media file for a
> correct MAM type. But I can't see where this would not acheive
> anything useful. If anybody can come up with a semi-valid reason, I
> will add the check(s).
> 
> 
> > 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.
> 
> Apart from a admin being able to determine the media type by the file
> name I can see no useful advantage of this. A small utility can quite
> easily read the MAM information and print out the relevant data.
> 
> There is a field in the MAM for 'Medium Serial Number'. When creating
> the virtual media, I set this with 'barcode_<ctime>'
> 
> Each 'block' of data written has a header which contains the following
> fields to describe the block of data:
> Block Type -> End of data, Beginning of data, file mark, data block
> etc.
> Block Size -> Size of raw data (uncompressed data size)
> Disk Block Size -> Size of data to be read/written from/to file. Or
> another way of putting it: how much data to skip to fine the next data
> block header.
> 
> The BLOCK TYPE field could be expaneded to specify the compression
> type used, however it has always been my intention to use the zlib
> compression library routines. It has never made it into any actual
> code.

will one backup job use different compression algorithm? so it is per
block or per job?

ps, i think these questions can have endless discussions. so let us do
Xp way, release it, get merged, make a VBE based regression test suite
and then we can always refactoring it and add more stuff.

a workable non-compression vt/vtl is good enough to draw many people
eyeballs.



> 
> 
> 
> >
> [snip]
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel