From nobody Wed Mar 30 19:33:11 2022 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 93AC71A54315 for ; Wed, 30 Mar 2022 19:33:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTGn31nTKz3NyP for ; Wed, 30 Mar 2022 19:33:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1E17118ED7 for ; Wed, 30 Mar 2022 19:33:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 22UJXB9e064260 for ; Wed, 30 Mar 2022 19:33:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22UJXBVp064259 for bugs@FreeBSD.org; Wed, 30 Mar 2022 19:33:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Wed, 30 Mar 2022 19:33:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ken@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ken@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648668791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ejhezZlEsc9X9cm/Pt/PANj5LR6ulBiPyvLxjSnsPz0=; b=F+nR9r5/jXDGadWFH4KUhqlS0Svb4CrAJe4v1I+OEmYmP3LZSGftuYlAIrJ0JIM3CjRUuS ZqSXBZXqVodJo7nQZr1aPFvaFTz621bxmrXNvnYdEA9siyYun6jBwSNlVJOQXEMvnjvXJX 7DM3G/mMkbA8GyecLlapizHp/xZvYcw49iKf20Ny2F8/Bzlsubrt25ldG2fAzrvu5WuiMu 9m0YWswrXG9WHeZsoMqaerkTAK0G1G172x2fETSmUqbCPZsMop9Yj3qnmX8a6Vr9ypbfbY cf/nOkAwuLpobZo1+v9wuOzhtn2ubOmSaFis+p6qrQQhyzUT75CULiuMBb60zg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648668791; a=rsa-sha256; cv=none; b=AH5Rh9y79l/4mwpPTospeDrI2I8gxvZ0JI76c+cYscJQZQgPeThWbx5nET00JNzdGGf96D RuaKmCf1Cwf2a/1ufTpqsYpBOTuoXESGMRFUV0iL5UWGoFX22iUAIZIzuBkwLdo5Un+FZd ggIZt1ppafXOUz6tpgQpvYUbKeG+rPPo2LFVg9pNWyu0sz6GtQE0d/m5Knb5n2NXRuwyNH q7tLM7JbdXuFqdxk3G2ztCZmg5zh9PBVK7qgqfExN6VHWbLabrRyVrWObE7bYfkXHptSC4 2MNkOZjX9wINvl2lOsrH3wExA4tC8uoQ935n01gxPIZ9cyVfBWNcjXl7/O1I8Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262904 Kenneth D. Merry changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |ken@FreeBSD.org CC| |ken@FreeBSD.org --- Comment #1 from Kenneth D. Merry --- 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: 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: 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.=