On 2022-11-08, Michael <confabul...@kintzios.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
