[gentoo-user] Re: e2fsck -c when bad blocks are in existing file?

[Grant Edwards]

On 2022-11-08, Michael <confabulate@××××××××.com> 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