[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.