Quantum Half Height Failure - I probably will submit a patch soon

[dylanetaft]

I notice this workaround implemented in

src/tape_drivers/linux/sg/sg_tape.c
	if (priv->vendor == VENDOR_HP) {
		priv->cart_type = assume_cart_type(priv->density_code);
		if (buf[2] == 0x01)
			priv->is_worm = true;
	} else {
		priv->cart_type = buf[2];
	}

	if (priv->cart_type == 0x00) {
		ltfsmsg(LTFS_WARN, 30265W);
		ltfs_profiler_add_entry(priv->profiler, NULL, TAPEBEND_REQ_EXIT(REQ_TC_LOAD));
		return 0;
	}

When I mkltfs my sg device,
I get some messages about "Failed to get medium type code: medium type check is skipped."
And then eventually
LTFS17254E This cartridge cannot be reformatted in the drive (0x00, 5).

I built from git.

I think I can fix this -

sg_modes -p 0x11 /dev/sg4
It does detect the tape properly

The if (priv->vendor == VENDOR_HP) seems like a bit of a hack - did whoever did this do it because the drive was pulling a tape of type 0x00 like mine?

This probably could be siphoned off to it's own workaround function. I can try and see if the commit for that has any notes about if their device was like mine, then the fix could share like a common code path - if the tape type is unknown, use the assume_cart_type workaround.

If so, then the fix is easy, and the workaround shares the same path.

I have a half height Quantum LTO-5.

Does this all sound reasonable for a fix? If so then I'll test and submit a PR.

Edit:
I will update this with relevant information as I collect info to support a proper fix. Unsure if I should just add some code to detect from the density or if another scsi command or page read should be used to read tape capacity. I will have to research. If there's better way to fix this that might help more devices, it would be good to have a fallback if media type falls outside of normal ranges - perhaps - rather than an override for this specific vendor which maybe is only needed on some drives.

sg_modes --page 0x3f /dev/sg4
    QUANTUM   ULTRIUM 5         3210   peripheral_type: tape [0x1]
Mode parameter header from MODE SENSE(10):
 00     00 de 00 10 00 00 00 08
  Mode data length=224, medium type=0x00, specific param=0x10, longlba=0
  Block descriptor length=8
> General mode parameter block descriptors:
   Density code=0x58
 00     58 00 00 00 00 00 02 00

>> Read-Write error recovery, page_control: current
 00     01 0a 08 15 00 00 00 00  0a 00 00 00
>> Disconnect-Reconnect, page_control: current
 00     02 0e 00 00 00 01 00 00  00 00 00 00 00 00 00 00
>> Control, page_control: current
 00     0a 0a 20 00 00 40 00 00  00 00 00 00
>> Data Compression, page_control: current
 00     0f 0e c0 80 00 00 00 01  00 00 00 01 00 00 00 00
>> Device configuration, page_control: current
 00     10 0e 00 00 00 00 01 2c  50 00 10 00 00 00 01 00
>> Medium Partition [1], page_control: current
 00     11 0a 01 00 3c 03 09 00  05 f9 00 00
>> Protocol specific logical unit (SPL), page_control: current
 00     18 06 16 00 00 00 00 00
>> Protocol specific port (SPL), page_control: current
 00     19 0e 06 00 07 d0 75 30  00 00 00 00 00 00 00 00
>> Power condition, page_control: current
 00     1a 26 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 20     00 00 00 00 00 00 00 00
>> Informational exceptions control (tape version), page_control: current
 00     1c 0a 08 03 00 00 00 00  00 00 00 01
>> Medium configuration, page_control: current
 00     1d 1e 00 00 01 02 00 00  00 00 00 00 00 00 00 00
 10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>> page_code: 0x21, page_control: current
 00     21 0e 05 04 01 00 80 00  02 00 00 00 00 00 00 00

sg_logs -p 0x17 /dev/sg4
This will read the chip in the LTO cart - not sure how standard it is.

Getting the cart_type from assume_cart_type DOES work for my drive, I can format the cart after hacking that in, still researching density values, or valid cart_type values, any standards around it..

The "hack" mentioned herefor VENDOR_HP was from commit 5e2b974 in 2020
The commit nor PR or comments give an indication as to the data the HP drive was returning from mode sense - which would have been great - if it was "0x00" then a common fix is possible.

So - I will apply this fix after that awkward if statement - I don't want to break HP devices if they actually return a valid but incorrect cart type.

Rough pseudo code is - if the cart_type isn't in the supported enum - then fallback to density with the existing vendor workaround function - no vendor checking needed.

/* LTO cartridge type in mode page header */
  enum {
    TC_MP_LTO1D_CART   = 0x18,   /* LTO1 Data cartridge */
    TC_MP_LTO2D_CART   = 0x28,   /* LTO2 Data cartridge */
    TC_MP_LTO3D_CART   = 0x38,   /* LTO3 Data cartridge */
    TC_MP_LTO4D_CART   = 0x48,   /* LTO4 Data cartridge */
    TC_MP_LTO5D_CART   = 0x58,   /* LTO5 Data cartridge */
    TC_MP_LTO6D_CART   = 0x68,   /* LTO6 Data cartridge */
    TC_MP_LTO7D_CART   = 0x78,   /* LTO7 Data cartridge */
    TC_MP_LTO8D_CART   = 0x88,   /* LTO8 Data cartridge */
    TC_MP_LTO9D_CART   = 0x98,   /* LTO9 Data cartridge */
    TC_MP_LTO10D_CART  = 0xA8,   /* LTO10 Data cartridge */
    TC_MP_LTOP10D_CART = 0xA9,   /* LTOP10 Data cartridge */
    TC_MP_LTO3W_CART   = 0x3C,   /* LTO3 WORM cartridge */
    TC_MP_LTO4W_CART   = 0x4C,   /* LTO4 WORM cartridge */
    TC_MP_LTO5W_CART   = 0x5C,   /* LTO5 WORM cartridge */
    TC_MP_LTO6W_CART   = 0x6C,   /* LTO6 WORM cartridge */
    TC_MP_LTO7W_CART   = 0x7C,   /* LTO7 WORM cartridge */
    TC_MP_LTO8W_CART   = 0x8C,   /* LTO8 WORM cartridge */
    TC_MP_LTO9W_CART   = 0x9C,   /* LTO9 WORM cartridge */
    TC_MP_LTO10W_CART  = 0xAC,   /* LTO10 WORM cartridge */
  };

I am pretty much done with my research. There should be a "staircase" of how cart_type is detected, not all vendors are the same.
It could be

1. from mode sense, if invalid
2. from density, if invalid
3. check out other things like log page 0x17 or there might need to be a per device override, not by vendor

I don't need option 3, that could be the next future change if anyone else runs into this issue in the future - I see a lot of issues regarding what I ran into here, this may fix many of them instead of just my own.

Will start working on patch...hmm one caveat is that ibm_tape.c does have an array supported_cart[]
vendor_compat is_supported_tape() uses it.

[dylanetaft]

It's working now ;)

Also, the code structure for ltfs is great, very easy to follow with how logging works and debug.

LTFS11330I Loading cartridge.
LTFS30298I Sense data returned unknown cart type, compat: assume_cart_type from density code (58 58)
LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
LTFS11332I Load successful.
LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
LTFS17157I Changing the drive setting to write-anywhere mode.
LTFS15049I Checking the medium (load).
LTFS30298I Sense data returned unknown cart type, compat: assume_cart_type from density code (58 58)
LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
LTFS15010I Creating data partition b on SCSI partition 1.
LTFS15011I Creating index partition a on SCSI partition 0.
LTFS17165I Resetting the medium's capacity proportion.
LTFS30298I Sense data returned unknown cart type, compat: assume_cart_type from density code (58 58)
LTFS11097I Partitioning the medium.
LTFS30298I Sense data returned unknown cart type, compat: assume_cart_type from density code (58 58)
LTFS11100I Writing label to partition b.
LTFS11278I Writing index to partition b.
LTFS17235I Writing index of 000000 to b (Reason: Format, 0 files) HU1149KVJ5.
LTFS17236I Wrote index of 000000 (Gen = 1, Part = b, Pos = 5, HU1149KVJ5).
LTFS11337I Update index-dirty flag (0) - 000000 (0x0xaaaad8601b10).
LTFS11100I Writing label to partition a.