Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: Rich Rauenzahn <rrauenza@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Western Digital Red's SMR and btrfs?
Date: Mon, 4 May 2020 23:26:55 -0400	[thread overview]
Message-ID: <20200505032654.GS10769@hungrycats.org> (raw)
In-Reply-To: <CAJCQCtTxtY696bFwhOscOHc5fjsRz_=EzO5Zf9spBFez_59Ltg@mail.gmail.com>

On Mon, May 04, 2020 at 08:22:24PM -0600, Chris Murphy wrote:
> On Mon, May 4, 2020 at 8:00 PM Zygo Blaxell
> <ce3g8jdj@umail.furryterror.org> wrote:
> >
> > On Mon, May 04, 2020 at 05:24:11PM -0600, Chris Murphy wrote:
> > > On Mon, May 4, 2020 at 5:09 PM Zygo Blaxell
> > > <ce3g8jdj@umail.furryterror.org> wrote:
> > >
> > > > Some kinds of RAID rebuild don't provide sufficient idle time to complete
> > > > the CMR-to-SMR writeback, so the host gets throttled.  If the drive slows
> > > > down too much, the kernel times out on IO, and reports that the drive
> > > > has failed.  The RAID system running on top thinks the drive is faulty
> > > > (a false positive failure) and the fun begins (hope you don't have two
> > > > of these drives in the same array!).
> > >
> > > This came up on linux-raid@ list today also, and someone posted this
> > > smartmontools bug.
> > > https://www.smartmontools.org/ticket/1313
> > >
> > > It notes in part this error, which is not a time out.
> >
> > Uhhh...wow.  If that's not an individual broken disk, but the programmed
> > behavior of the firmware, that would mean the drive model is not usable
> > at all.
> 
> I haven't gone looking for a spec, but "sector ID not found" makes me
> think of a trim/remap related failure, which, yeah it's gotta be a
> firmware bug. This can't be "works as designed".

Usually IDNF is "I was looking for a sector, but I couldn't figure out
where on the disk it was," i.e. head positioning error or damage to the
metadata on a cylinder or sector header.  Though there are maybe some
that return IDNF instead of ABRT when they get a request for a sector
outside of the drive's legal LBA range.

The "didn't find a sector" variant usually indicates non-trivial damage
(impact on platter vs. bit fade), but could also be due to too much
vibration and a short read error timeout.  Also a small fraction of
bit errors will land on sector headers and produce IDNF without
other damage.

> 
> -- 
> Chris Murphy

  reply	other threads:[~2020-05-05  3:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02  5:24 Western Digital Red's SMR and btrfs? Rich Rauenzahn
2020-05-04 23:08 ` Zygo Blaxell
2020-05-04 23:24   ` Chris Murphy
2020-05-05  2:00     ` Zygo Blaxell
2020-05-05  2:22       ` Chris Murphy
2020-05-05  3:26         ` Zygo Blaxell [this message]
2020-05-09 21:00   ` Phil Karn
2020-05-09 21:46     ` Steven Fosdick
2020-05-11  5:06       ` Zygo Blaxell
2020-05-11 20:35         ` Phil Karn
2020-05-11 21:13           ` Alberto Bursi
2020-05-11 22:42             ` Phil Karn
2020-05-12  0:12               ` Zygo Blaxell
2020-05-12  2:17               ` Alberto Bursi
2020-05-11  4:06     ` Damien Le Moal
2020-05-05  9:30 ` Dan van der Ster
  -- strict thread matches above, loose matches on Subject: below --
2020-05-02 12:26 Torstein Eide

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=20200505032654.GS10769@hungrycats.org \
    --to=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=rrauenza@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