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

[Laurence Perkins]

Ok, so I decided to just go and test it myself.  

I created a 2MiB file and formatted it as ext4 and mounted it.
I created a single, 100KiB file with a test pattern in this filesystem, and then unmounted it.
I found the file in the raw storage with a hex editor, and computed a block offset in the middle of it.
I swapped out my badblocks executable with a dummy that just spits out that block as "bad".
I ran fsck.ext4 -c on the storage file.

Fsck.ext4 calls badblocks, which returns that one, "bad" block.  Fsck.ext4 then automatically adds that block to the badblocks inode immediately.
Then it continues with its checks, and when it gets to the part where it's checking for inode issues, it informs you that there is a block claimed by both a file inode and the badblocks inode and would you like to try to clone it into separate copies for each.

Presumably there's some logic in there to make sure that the new cloned copy goes to the file and not to the badblocks inode, but I can't be bothered to dig into it that far.  I'll just assume that the fsck developers have at least a half a clue.

Regardless, at that point the user gets to choose if they want fsck to try to fix it automatically, or if they want to use a more subtle tool to see if they can coax one more read out of the block in question.  But whether they clone the file, data-recovery-tool the file, or simply delete the file and move on, that bad sector is on the bad list and won't get allocated again.

Hopefully this answers the question sufficiently.

LMP

-----Original Message-----
From: Grant Edwards <grant.b.edwards@×××××.com> 
Sent: Wednesday, November 9, 2022 4:19 PM
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: e2fsck -c when bad blocks are in existing file?

On 2022-11-09, Wol <antlists@××××××××××××.uk> wrote:
> On 09/11/2022 23:31, Grant Edwards wrote:
>>> 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 doubt you recall correctly.

The e2fsck man page states explicitly that a -c read failure will cause the block to be added to the bad block inode. You're claiming that is not what happens?

> You should ONLY EVER conclude a block is bad if you can't write to it.
> Remember what I said - if I read my 8TB drive from end-to-end twice,
> then I should *expect* a read error ...

OK...

>> I'm asking what happens to the file containing the bad block.
>> Perphaps nothing. The man page says the block is added to the "bad
>> block inode". If that block was already allocated, is the bad block
>> is now allocated to two different inodes?
>
> If a read fails, you SHOULD NOT do anything.

Thanks, but I'm not asking what I should do. I'm not asking what the filesystem should do.  I'm not asking what disk-drive controller firmware should do or does do with failed/spare blocks.

I'm asking what e2fsck -c does when the bad block is already allocated to an inode. Specifically:

  Is the bad block removed from the inode to which it was allocated?

  Is the bad block left allocated to the previous inode as well as
  being added to the bad block inode?

We've gotten lots of answers to lots of other questions, but after re-reading the thread a few times, I still haven't seen an answer to the question I asked.

> If a write fails, you move the block and mark the failed block as bad.
> But seeing as you've moved the block, the bad block is no longer
> allocated to any file ...

Are you stating e2fsck -c will removed bad block from the inode to which it was allocated before the scan? Is it replaced with a different block? Or just left as an empty "hole" that can't be read from or written to?

The e2fsck man page does not state that the bad block is removed from the old inode, only that that bad block is added to the bad block inode.

If a block is allocated to an inode, I would call that "allocated to a file". It's not a file that has a visible name that shows up in a directory, but it's still a file.

--
Grant