linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Christopher Staples <mastercatz@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: bad sector / bad block support
Date: Wed, 27 Nov 2019 09:15:41 -0500	[thread overview]
Message-ID: <c1473267-688c-201f-11e5-64761ad51f79@gmail.com> (raw)
In-Reply-To: <CAGsZeXsEZ8EqPsuU9O+7d+suxBVNQAobASJaLNMZB9LhUe6Q7A@mail.gmail.com>

On 2019-11-26 22:30, Christopher Staples wrote:
> will their ever be a better way to handle bad sectors ?  I keep
> getting silent corruption from random bad sectors
> scrubs keep passing with out showing any errors , but if I do a
> ddrescue backup to a new drive I find the bad sectors
Zygo is correct, if there are no checksum errors, it's almost certainly 
not the storage device.

Put simply, for a media error to cause corruption without a checksum 
error, all of the following need to happen at the same time:

* At least one sector in a data block has to go bad without the storage 
device's built-in error correction catching it. If the ECC functionality 
of the drive caught it, it would either return the correct data or a 
read error. This is actually rather unlikely for small numbers of 
devices (but the likelihood of it happening goes up as you increase the 
number of devices involved).
* A mix of similar errors in the block containing the checksum for the 
data block has to similarly go bad without being detected or corrected 
and it has to match up with the corrupted data _or_ the checksum for the 
corrupted data block has to be valid for the corrupted data. This is 
astronomically unlikely, to a level that you're far more likely to be 
struck and killed by a meteor than this happening.
* The above then has to happen for the checksum for the metadata block 
containing the checksum for that data block, and in turn the same 
condition has to repeat for each block up the tree to the root (usually 
3+ times). This is so unlikely to be a statistical impossibility.

So, as Zygo suggests, check your RAM, check your CPU, possibly check 
your PSU (bad power supplies can cause all kinds of weird things).
> 
> 
> the only thing I can do for now is mark I/O error files as bad buy
> renaming them and make another file copy onto the file system ,
> 
> 
> I like btrfs for the snapshot ability , but when it comes to keeping
> data safe ext4 seems better ? at least it looks for bad sectors and
> marks them , btrfs just seems to write and assumes its written ..

ext4 wouldn't save you here, because you almost certainly aren't dealing 
with bad sectors.

BTRFS doesn't include bad sector support like ext4 because it solves the 
issue a different way, namely by checksumming everything and then 
validating the checksums on read.

On a slightly separate note, you should never need the ext4 bad block 
functionality on any modern hardware unless your storage devices are way 
beyond the point at which they should be replaced.  The original reason 
for having bad block lists in the filesystem was that disk drives didn't 
remap bad sectors, which in turn meant that the filesystem had to deal 
with them. It's been multiple decades since that was the case though, 
and all modern storage devices (except possibly some really cheap USB 
flash drives) remap bad sectors and only let the OS see them when they 
run out of space to remap them to.

  parent reply	other threads:[~2019-11-27 14:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  3:30 bad sector / bad block support Christopher Staples
2019-11-27  3:48 ` Zygo Blaxell
2019-11-27 14:15 ` Austin S. Hemmelgarn [this message]
2019-11-27 15:42   ` Graham Cobb
2019-11-28  1:23 ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1473267-688c-201f-11e5-64761ad51f79@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mastercatz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).