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 |