mhvtl
mhvtl copied to clipboard
markh794
Add Support for LTO7M8 tapes.
LTO7M8 tapes are LTO7 cartridges written by LTO8 drives. This enables 9TB to be stored on a tape designed for 6TB. I have added these , but I am unsure of the media_type_lto7m8_data value in usr/vtltape.h.
Note: LTO7M8 does NOT support WORM style tapes.
According to the scsi ref for LTO8, there is no separate type value. To identify it as a higher volume capacity when used on the later gen drive, they have borrowed the volume personality feature from 3592 as that always had this ability to increase capacity of older generation tapes in new drives.
From ref document
The volume personality parameter contains an ASCII string to identify the combination of physical volume type and density formatted on the medium. The intent is to provide a designator sufficient for successful volume
interchange.
LTO-5 to LTO-7: The value is in the format “Ultrium-”+”
The medium type should be the same as LTO-7 (78h) - This is byte[2] in the Mode Parameter Header for Mode Select. Now we have the 'LTO-7-M8' type defined, now we need to update the LTO-8 emulation to set the MAM data from LTO-7 to LTO-7-M8 if a write occurs. Still researching how an LTO-7 drive would cope with the newly written media format. I'm assuming it should be backwards compatible. If you can re-submit this patch with the correct Medium Type, then a subsequent patch can update the LTO-8 & LTO-7 drive handling of the media
It is a one way change once you write as LTO7 it cannot be changed to an M8 and vice versa and an LTO7 drive cannot read the M8 tapes. I would expect this is due to increased track density and it is not backward compatible from LTO 9 either. LTO9 I believe can only read and write LTO8 and LTO9 media
It is a one way change once you write as LTO7 it cannot be changed to an M8 and vice versa and an LTO7 drive cannot read the M8 tapes. I would expect this is due to increased track density and it is not backward compatible from LTO 9 either. LTO9 I believe can only read and write LTO8 and LTO9 media
I'm assuming this LTO-8M a write at BOT only type of change. i.e. An LTO-7 writes a lump of data, the media then loads into an LTO-8 drive and if writes at BOT, the media is updated to LTO-7M8, otherwise the LTO-8 appends using the default LTO-7 media format.
It is a one way change once you write as LTO7 it cannot be changed to an M8 and vice versa and an LTO7 drive cannot read the M8 tapes. I would expect this is due to increased track density and it is not backward compatible from LTO 9 either. LTO9 I believe can only read and write LTO8 and LTO9 media
I'm assuming this LTO-8M a write at BOT only type of change. i.e. An LTO-7 writes a lump of data, the media then loads into an LTO-8 drive and if writes at BOT, the media is updated to LTO-7M8, otherwise the LTO-8 appends using the default LTO-7 media format.
Checking out 'compatibility' section on Wikipedia is answering my questions. The IBM SCSI reference I have is as clear as mud.
And the HPE LTO-7 cartridge initialised as Type M media is a gold mine.. Rules are bascially:
- Only media in libraries can be initialised as M8 (and the media contains an 'M8' suffix on the barcode).
- Only if the media has never been written to. HPE do state that an error is returned if a tape with L8 suffix is unmounted with M8 format - however they neglect to state how & what the error is.
I was previously looking for the scsi commands to set the lto8 drive to the m8 mode so new lto7 tapes would be initialised as an M8 but no luck there. I did find a reference to it on the releases notes for the sl8500 firmware update for M8 and said that ADI mode has to be on so I guess their setting it through the ethernet or rs422 connections via the library and that also be how their getting the error returned also.
The HPE document did state that M8 media can not be initialised by stand-alone drives (but stand alone can read the M8 format). Hence it can not be a simple SCSI OP code - otherwise the OP code could be sent to the stand-alone drive. Or perhaps this is to prevent media with '
This may require a re-think of mhVTL mount logic. Currently all media can be moved into any drive type - the drive rejects any format not suitable - even inserting 4mm into LTO (as there is no physical barriers in a virtual library).
As an immediate work-around, update 'edit_tape' & 'mktape' commands to create M8 type media. i.e. no automation of the 'conversion' process.
Thanks for the comments. I will have a read through and submit an update later tonight.
Perhaps I should have submitted the T10KD cartridge PR first!
The HPE document did state that M8 media can not be initialised by stand-alone drives (but stand alone can read the M8 format). Hence it can not be a simple SCSI OP code - otherwise the OP code could be sent to the stand-alone drive. Or perhaps this is to prevent media with 'L7' being initialised as M8, as the media mount rules of the library will/should not permit the mount.
This may require a re-think of mhVTL mount logic. Currently all media can be moved into any drive type - the drive rejects any format not suitable - even inserting 4mm into LTO (as there is no physical barriers in a virtual library).
As an immediate work-around, update 'edit_tape' & 'mktape' commands to create M8 type media. i.e. no automation of the 'conversion' process.
As per : https://www.ibm.com/docs/en/ts4500-tape-library?topic=media-lto-type-m-cartridge-m8, The 'mktape' / 'edit_tape' path would result in the 'pre-initialized' media. This would be a simple addition to the above patch. Working through the logic for 'uninitialised' -M8 via the library path will be lots more 'fun'