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 77014158020 for ; Tue, 8 Nov 2022 14:28:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00216E09DC; Tue, 8 Nov 2022 14:28:10 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [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 (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 27E32E09CD for ; Tue, 8 Nov 2022 14:28:10 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1osPaC-0002gt-Tg for gentoo-user@lists.gentoo.org; Tue, 08 Nov 2022 15:28:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file? Date: Tue, 8 Nov 2022 14:28:02 -0000 (UTC) Message-ID: References: <3193783.oiGErgHkdL@lenovo.localdomain> User-Agent: slrn/1.0.3 (Linux) 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 X-Archives-Salt: f6241d14-d9e1-4d88-8c03-554dbcabee88 X-Archives-Hash: a302c5795c5e47f1f53cf66811562f3b 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