On Tue, 08 Nov 2022 12:55:51 -0500,
Laurence Perkins wrote:
>
>
>
> >-----Original Message-----
> >From: Grant Edwards <[email protected]>
> >Sent: Tuesday, November 8, 2022 6:28 AM
> >To: [email protected]
> >Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file?
> >
> >On 2022-11-08, Michael <[email protected]> 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
>
> If I recall correctly, it will add any unreadable blocks to its internal list
> of bad sectors, which it will then refuse to allocate in the future.
>
> I don't believe it will attempt to move the file to elsewhere until it is
> written since:
> A) what would you then put in that block? You don't know the contents.
> B) Moving the file around would make attempts to recover the data from that
> bad sector significantly more difficult.
>
> This is, however, very unlikely to come up on a modern disk since most of
> them automatically remap failed sectors at the hardware level (also on write,
> for the same reasons). So the only time it would matter is if you have a
> disk that's more than about 20 years old, or one that's used up all its spare
> sectors...
>
> Unless, of course, you're resurrecting the old trick of marking a section of
> the disk as "bad" so the FS won't touch it, and then using it for raw data of
> some kind...
>
> You can, of course, test it yourself to be certain with a loopback file and a
> fake "badblocks" that just outputs your chosen list of bad sectors and then
> see if any of the data moves. I'd say like a 2MB filesystem and write a file
> full of 00DEADBEEF, then make a copy, blacklist some sectors, and hit it with
> your favorite binary diff command and see what moved. This is probably
> recommended since there could be differences between the behaviour of
> different versions of e2fsck.
Maybe its time for spinwrite -- new version coming out soon, but it
might save your bacon.
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
[email protected]
