From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E92AD158020 for ; Tue, 8 Nov 2022 18:49:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93796E0A10; Tue, 8 Nov 2022 18:49:54 +0000 (UTC) Received: from mail-gw.thundermail.uk (mail-gw.thundermail.uk [149.255.60.74]) (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) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 28DBBE09F5 for ; Tue, 8 Nov 2022 18:49:53 +0000 (UTC) Received: from mailgw01.thundermail.uk (uwhmailfgw01.unlimited.uk.net [149.255.60.67]) by mail-gw.thundermail.uk (Postfix) with ESMTPS id 9BD9B600054F for ; Tue, 8 Nov 2022 18:49:52 +0000 (GMT) X-ASG-Debug-ID: 1667933391-0554133dd0e37b20001-LfjuLa Received: from mailclean01.thundermail.uk (mailclean01.thundermail.uk [149.255.60.66]) by mailgw01.thundermail.uk with ESMTP id bKlQ0rXDjiVFWDHO (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 08 Nov 2022 18:49:51 +0000 (GMT) X-Barracuda-Envelope-From: confabulate@kintzios.com X-Barracuda-Effective-Source-IP: mailclean01.thundermail.uk[149.255.60.66] X-Barracuda-Apparent-Source-IP: 149.255.60.66 Received: from cloud220.unlimitedwebhosting.co.uk (cloud220.unlimitedwebhosting.co.uk [149.255.60.183]) by mailclean01.thundermail.uk (Postfix) with ESMTPS id 2DF724190A for ; Tue, 8 Nov 2022 18:49:46 +0000 (GMT) Received: from lenovo.localdomain (230.3.169.217.in-addr.arpa [217.169.3.230]) by cloud220.unlimitedwebhosting.co.uk (Postfix) with ESMTPSA id E6A14D4E953 for ; Tue, 8 Nov 2022 18:49:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kintzios.com; s=default; t=1667933387; bh=udpUYYCsa4LQ0sFn4Qo0EqG/E8awwWMaas1OjBup+Og=; h=From:To:Subject; b=bJYPCP3y7pr6nGVq2m9dxwI1tuf3e+fL/MrFn9cJ2dME4GmWwtk1vnkHkrAhQtr2e o/I3uRON+KOVjnM4vEG/TpGkemLVrvcA2Ba5VQVqUPL9ZrkM796g6TybrARQwh44q7 4NvPlM5I9rqD+ftdypq2fWSTvEKpBGpv+nU0kxyM= From: Michael To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? Date: Tue, 08 Nov 2022 18:49:27 +0000 X-ASG-Orig-Subj: Re: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? Message-ID: <4033480.6PsWsQAL7t@lenovo.localdomain> In-Reply-To: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20596426.0c2gjJ1VT2"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-PPP-Message-ID: <166793338724.2205920.4016334009399986834@cloud220.unlimitedwebhosting.co.uk> X-PPP-Vhost: kintzios.com X-Spam-Status: No, score=-0.2 required=11.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_PASS autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from * envelope-from domain X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mailclean01.thundermail.uk X-Barracuda-Connect: mailclean01.thundermail.uk[149.255.60.66] X-Barracuda-Start-Time: 1667933391 X-Barracuda-Encrypted: TLS_AES_256_GCM_SHA384 X-Barracuda-URL: https://149.255.60.67:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at thundermail.uk X-Barracuda-Scan-Msg-Size: 4755 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.102000 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: e7c2243d-823d-4705-aade-67db334f76d9 X-Archives-Hash: a191931e40f04b518600243cce068eea --nextPart20596426.0c2gjJ1VT2 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Michael To: gentoo-user@lists.gentoo.org Reply-To: confabulate@kintzios.com Date: Tue, 08 Nov 2022 18:49:27 +0000 Message-ID: <4033480.6PsWsQAL7t@lenovo.localdomain> MIME-Version: 1.0 On Tuesday, 8 November 2022 17:55:51 GMT Laurence Perkins wrote: > >-----Original Message----- > >From: Grant Edwards > >Sent: Tuesday, November 8, 2022 6:28 AM > >To: gentoo-user@lists.gentoo.org > >Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? > > > >On 2022-11-08, Michael wrote: > >> On Tuesday, 8 November 2022 03:31:07 GMT Grant Edwards wrote: > >>> I've got an SSD that's failing, and I'd like to know what files > >>> contain bad blocks so that I don't attempt to copy them to the > >>> replacement disk. > >>> > >>> According to e2fsck(8): > >>> -c This option causes e2fsck to use badblocks(8) program to > >>> do > >>> > >>> a read-only scan of the device in order to find any bad blocks. If > >>> > >>> any bad blocks are found, they are added to the bad block inode to > >>> prevent them from being allocated to a file or directory. If this > >>> option is specified twice, then the bad block scan will be done > >>> using a non-destructive read-write test. > >>> > >>> What happens when the bad block is _already_allocated_ to a file? > >> > >> Previously allocated to a file and now re-allocated or not, my > >> understanding is with spinning disks the data in a bad block stays > >> there unless you've dd'ed some zeros over it. Even then read or write > >> operations could fail if the block is too far gone.[1] Some data > >> recovery applications will try to read data off a bad block in > >> different patterns to retrieve what's there. Once the bad block is > >> categorized as such it won't be used by the filesystem to write new data > >> to it again.> > >Thanks. I guess I should have been more specific in my question. > > > >What does e2fsck -c do to the filesystem structure when it discovers a bad > >block that is already allocated to an existing inode? > > > >Is the inode's chain of block groups left as is -- still containing the bad > >block that (according to the man page) "has been added to the bad block > >inode"? Presumably not, since a block can't be allocated to two different > >inodes. > > > >Is the "broken" file split into two chunks (before/after the bad > >block) and moved to the lost-and-found? > > > >Is the man page's description only correct when the bad block is currently > >unallocated? > > > >-- > >Grant > > If I recall correctly, it will add any unreadable blocks to its internal > list of bad sectors, which it will then refuse to allocate in the future. > > I don't believe it will attempt to move the file to elsewhere until it is > written since: A) what would you then put in that block? You don't know > the contents. B) Moving the file around would make attempts to recover the > data from that bad sector significantly more difficult. As far as I know trying to write raw data directly to a bad block e.g. with dd or hdparm will trigger the disk's controller firmware to reallocate the data from the bad block to a spare. I always thought e2fsck won't write data in a block unless it is empty. badblocks -w will write test patterns to blocks and also trigger data reallocation on any bad blocks. badblocks -n, which corresponds to e2fsck -cc will only write to empty blocks and it may or may not trigger a firmware reallocation. I'm not sure what happens at a filesystem level, when one bad block within an extent is reallocated. The extent and the previously contiguous blocks will no longer be contiguous. Does the hardware expose some SMART data to inform the OS/fs of the reallocated block, to perform a whole extent remapping? > This is, however, very unlikely to come up on a modern disk since most of > them automatically remap failed sectors at the hardware level (also on > write, for the same reasons). So the only time it would matter is if you > have a disk that's more than about 20 years old, or one that's used up all > its spare sectors... > > Unless, of course, you're resurrecting the old trick of marking a section of > the disk as "bad" so the FS won't touch it, and then using it for raw data > of some kind... > > You can, of course, test it yourself to be certain with a loopback file and > a fake "badblocks" that just outputs your chosen list of bad sectors and > then see if any of the data moves. I'd say like a 2MB filesystem and write > a file full of 00DEADBEEF, then make a copy, blacklist some sectors, and > hit it with your favorite binary diff command and see what moved. This is > probably recommended since there could be differences between the behaviour > of different versions of e2fsck. > > LMP --nextPart20596426.0c2gjJ1VT2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmNqpLcACgkQseqq9sKV ZxlB/xAA3MkR4wRML5waVZIw7vXKjvVKyAGgqwhfmMSLdkuuPgYRKIoG5gqcFTaq hOu9e0AKzCNDYyZvwv5iqPs/NzhVpg1qiKIMCNhXdevGILLmRnk6pKd9IqwRquGI vmpIxIV5/Rid5psSYVxET54kzg3GhNoe1A43/LTwnEvSwEP5ZErb9JQSEHr19YTK 6MuB5FeWL9UXRUMh5okgGH6CHbY64zQl+Zx4PR1lc1rBf4/7J/X91AA2aIPpeiny r8thkUEXzblBnqu6j/9W5wmNOJOXcuH3mYGdsB50NtPXzbEKDCRCCkQSt85p3yYZ dNH/j8dvctP4c4ftUR4lD8Mhd5sciugGsJCpbBWjbTZFGXGKfjIqAocVJXn9SUkA ajRGqqNuYGThQczXp7NdzNt+bVILLgGXc2QBAst21WWmGD6Lh4Dq4JEuAW2SEKAF WD2KK87FSKmqMhIV8FMqu1qjgKzTNOqzGxca1rT6n8fV1gEkIbLtNkho6BEYeCbg WIEj/gqRrje/u5D2azPnRKhSPk05Y/4j/YaWw4P7/qJ/NxnKCl3EIspIzeM/iRjf STlOQ7ybNIQmxt8g1jGnD0ryPR+kwYEyOrXzvsoV5sZE2+QaaXtb3GqrvchPccTW 5NZEhmCaidWAy5YbZGVZ+8gFY96e4WeTzLd/FrhpZA+uwuESfhY= =8Dhw -----END PGP SIGNATURE----- --nextPart20596426.0c2gjJ1VT2--