From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glkdd-dm-crypt@m.gmane-mx.org>
Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de
 [116.202.254.214])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Wed,  8 Jul 2020 02:48:31 +0200 (CEST)
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <glkdd-dm-crypt@m.gmane-mx.org>) id 1jsyBM-0004U9-In
 for dm-crypt@saout.de; Wed, 08 Jul 2020 02:43:28 +0200
From: Robert Nichols <rnicholsNOSPAM@comcast.net>
Date: Tue, 7 Jul 2020 19:43:22 -0500
Message-ID: <re34rb$ge8$1@ciao.gmane.io>
References: <3vDyxLyWr_rNbnR7rY0pHQ1ax-duBWq_KHokpmZ9DtfRU5AAWUbnKZSwNrX2isMmPfs4DQk9DMBz4Y-o9QNsVjHOHvLguizYpfIV-4vKSxw=@protonmail.com>
 <a18449a3-644e-4478-96dc-268ed9a5d70c@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
In-Reply-To: <a18449a3-644e-4478-96dc-268ed9a5d70c@localhost>
Content-Language: en-US
Subject: Re: [dm-crypt] Help request
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <https://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <https://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <https://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 7/7/20 3:58 PM, Michael Kjörling wrote:
> On 6 Jul 2020 03:36 +0000, from lacedaemonius1@protonmail.com (lacedaemonius):
>> [ 643.631782] print_req_error: critical target error, dev sdi, sector 11721044993
>> [ 643.631789] Buffer I/O error on dev sdi, logical block 11721044993, async page read
...
> Unfortunately, drives can fail without reporting failures in SMART
> data, and they can fail early. While the probability of either is
> _lower_, it is non-zero.

And, a single bad sector is not going to cause SMART to report a failure.
"FAILING NOW" is not reported until the drive has nearly exhausted its
supply of spare sectors.

The good news is that this LBA, right at the end of a 6TB (nominal)
drive, is a fairly unlikely location for a LUKS header, so even if
this is an actual bad sector your data should be otherwise recoverable.

The output from "smartctl -A" (or the fuller report from "-a") should
be relevant, in particular the "Current_Pending_Sector" raw value.
A non-zero value there indicates bad sectors that are visible to the
OS and will cause an I/O error when read.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.