[Bug 262904] Write errors when writing to LTO tape with dd, tar, btape etc. after upgrade to 13.0-RELEASE

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 30 Mar 2022 19:33:11 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262904

Kenneth D. Merry <ken@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|bugs@FreeBSD.org            |ken@FreeBSD.org
                 CC|                            |ken@FreeBSD.org

--- Comment #1 from Kenneth D. Merry <ken@FreeBSD.org> ---
There are differences between 12.x and 13.0, but in looking through the diffs
it isn't obvious what could be causing this issue. (FYI, I looked through the
mpt(4) driver, sa(4) driver, dd(1), CAM error recovery code...).

So, we'll need to do some diagnostics to help figure it out.

First off, let's verify what blocksize your controller and drive support.  To
do that, run mt status -v

e.g.:
{blackpearl:/root:!:0} mt status -v
Drive: sa0: <IBM ULTRIUM-HH6 H991> Serial Number: 1013005128
---------------------------------
Mode      Density              Blocksize      bpi      Compression
Current:  0x5a:LTO-6           variable       384607   enabled (0xff)
---------------------------------
Current Driver State: at rest.
---------------------------------
Partition:   0      Calc File Number:   0     Calc Record Number: 0
Residual:    0  Reported File Number:   0 Reported Record Number: 0
Flags: BOP
---------------------------------
Tape I/O parameters:
  Maximum I/O size allowed by driver and controller (maxio): 2097152 bytes
  Maximum I/O size reported by controller (cpi_maxio): 5201920 bytes
  Maximum block size supported by tape drive and media (max_blk): 8388608 bytes
  Minimum block size supported by tape drive and media (min_blk): 1 bytes
  Block granularity supported by tape drive and media (blk_gran): 0 bytes
  Maximum possible I/O size (max_effective_iosize): 2097152 bytes

The last number is what we're interested in.  You can't write blocks larger
than that to the tape.

Load a tape in the drive, and see how much space it claims to have.  To do
that, run:

camcontrol attrib sa0 -v -r attr_val |less

The first two lines should show you:

Remaining Capacity in Partition (0x0000)[8](RO): 34826 MB
Maximum Capacity in Partition (0x0001)[8](RO): 35060 MB

In this case, this is from a LTFS-partitioned LTO-6 tape, thus the unusual size
for the first partition.

So, let's see how much data we can fit on the partition that is nominally 35GB.

{blackpearl:/root:!:0} dd if=/dev/urandom of=/dev/nsa0 bs=1m
dd: /dev/nsa0: end of device
17522+0 records in
17521+0 records out
18372100096 bytes transferred in 148.136615 secs (124021330 bytes/sec)

17GB.  Let's see what the sense data says:

{blackpearl:/root:!:0} mt errstat
Last I/O Residual: 0
 Last I/O Command: 0A 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00
   Last I/O Sense:

         F0 00 40 00 00 00 00 58 00 00 00 00 00 07 30 00
         62 62 00 00 02 01 30 31 38 36 39 32 4C 01 00 01

Last Control Residual: 0
 Last Control Command: 10 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
   Last Control Sense:

         F0 00 40 00 00 00 00 58 00 00 00 00 00 07 30 00
         62 62 00 00 02 01 30 31 38 36 39 32 4C 01 00 01


The last I/O command was a write (0xa), 1MB in size.

The sense data (see 0x40 in byte 2) is the EOM bit.  So, that would probably be
the PEW (Programmable Early Warning) in this case.

{blackpearl:/tmp/tapetest:!:0} mt status -v
Drive: sa0: <IBM ULTRIUM-HH6 H991> Serial Number: 1013005128
---------------------------------
Mode      Density              Blocksize      bpi      Compression
Current:  0x5a:LTO-6           variable       384607   enabled (0xff)
---------------------------------
Current Driver State: at rest.
---------------------------------
Partition:   0      Calc File Number:   1     Calc Record Number: 0
Residual:    0  Reported File Number:   1 Reported Record Number: 17522
Flags: BPEW
---------------------------------
Tape I/O parameters:
  Maximum I/O size allowed by driver and controller (maxio): 2097152 bytes
  Maximum I/O size reported by controller (cpi_maxio): 5201920 bytes
  Maximum block size supported by tape drive and media (max_blk): 8388608 bytes
  Minimum block size supported by tape drive and media (min_blk): 1 bytes
  Block granularity supported by tape drive and media (blk_gran): 0 bytes
  Maximum possible I/O size (max_effective_iosize): 2097152 bytes

We see the BPEW (Beyond Programmable Early Warning) status on the position
information.

So that is why we got the short write after only 17.5GB.  

So, do the dd write test, and then do mt errstat and mt status -v after the dd
ends, and attach the output to the this bug.

With dd (or anything else) make sure to use a blocksize that is less than or
equal to the maximum possible I/O size listed by mt status -v.

We'll see what the sense data says, and what the position data says, and then
figure out what the next debugging step is based on that.

-- 
You are receiving this mail because:
You are the assignee for the bug.