[Bug 262904] Write errors when writing to LTO tape with dd, tar, btape etc. after upgrade to 13.0-RELEASE
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.