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

[Laurence Perkins]

>
>
> -----Original Message-----
> From: Grant Edwards <grant.b.edwards@×××××.com>
> Sent: Saturday, November 12, 2022 7:55 PM
> To: gentoo-user@l.g.o
> Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file?
>
> On 2022-11-12, Michael <confabulate@××××××××.com> wrote:
>
> > Have your questions been answered satisfactorily by Lawrence's contribution?
>
> Yes, Lawrence's experiment answered the my question: e2fsck adds the bad block to the "bad block" inode and leaves it also allocated to the existing file.
>
> Presumably if you don't allow it to clone the block, reading that file will return an error when it gets to the bad block. Once you delete that file, the bad block will never get reallocated by the filesystem since it still belongs to the bad block inode.
>
> The failing SSD that prompted the question has now been replaced and a fresh Gentoo system installed on the new drive. I never did figure out which files contained the bad blocks (there were 37 bad blocks, IIRC). They apparently didn't belong to any of the files I copied over to the replacement drive.
>
> The old drive was a Samsung 850 EVO SATA drive, and the new one is a Samsung 980 PRO M.2 drive. The new one is noticably faster than the old one (which in turn was way faster than the spinning platter drive it had replaced).
>
> --
> Grant

Multiply-allocated blocks won't cause an error by themselves.  They can just cause strange and unexpected munging of your data if two files are scribbling on the same patch of disk.  So if you leave it allocated to both then you can use a more intelligent tool to either coax one more read out of it or potentially replace the lost data with some substitute.

I'm not sure what fsck will do with a read error while cloning the block since my test "disk" wasn't actually bad.  Presumably fill the bad section with nulls.

LMP