Date: Wed, 30 Mar 2022 19:33:11 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262904] Write errors when writing to LTO tape with dd, tar, btape etc. after upgrade to 13.0-RELEASE Message-ID: <bug-262904-227-tXJqChbGUa@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262904-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262904-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262904 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 dif= fs it isn't obvious what could be causing this issue. (FYI, I looked through t= he 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 b= ytes 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 3= 5GB. {blackpearl:/root:!:0} dd if=3D/dev/urandom of=3D/dev/nsa0 bs=3D1m 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 probabl= y 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 b= ytes 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.=20=20 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 th= en figure out what the next debugging step is based on that. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262904-227-tXJqChbGUa>