[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    RE: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file?
From:       Laurence Perkins <lperkins () openeye ! net>
Date:       2022-11-14 16:37:48
Message-ID: MW2PR07MB4058B3E947CD59BDBCE90F53D2059 () MW2PR07MB4058 ! namprd07 ! prod ! outlook ! com
[Download RAW message or body]

> 
> 
> -----Original Message-----
> From: Grant Edwards <grant.b.edwards@gmail.com> 
> Sent: Saturday, November 12, 2022 7:55 PM
> To: gentoo-user@lists.gentoo.org
> Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file?
> 
> On 2022-11-12, Michael <confabulate@kintzios.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


[prev in list] [next in list] [prev in thread] [next in thread]