All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: Clemens Eisserer <linuxhippy@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: How does btrfs handle bad blocks in raid1?
Date: Thu, 09 Jan 2014 16:46:58 -0800	[thread overview]
Message-ID: <52CF4302.6020403@chinilu.com> (raw)
In-Reply-To: <CAFvQSYRDbdDaJDAUVuUq9pqh+EryJO_=jZGjEEedSOVj71SS+g@mail.gmail.com>

Hello Clemens,

On 01/09/2014 04:08 PM, Clemens Eisserer wrote:
> Hi George,
>
>> I really suspect a lot of bad block issues can be avoided by monitoring
>> SMART data.  SMART is working very well for me with btrfs formatted drives.
>> SMART will detect when sectors silently fail and as those failures
>> accumulate, SMART will warn in an obvious way that the drive in question is
>> at end of life.  So I think the whole bad block issue should ideally be
>> handled at a lower level than filesystem with modern hard drives.
> At least my original request was about cheap flash media, where you
> don't have the luxury that you can "trust" the hardware behaving
> properly. In fact, it might be benefitial for a SD card to not report
> ECC errors - most likely the user won't notice a small glitch playing
> back music - but he definitively will when the smartphone reports read
> errors and stopping playback which will cause that card to be RMAd.
>
> Also, wouldn't your argument be also valid for checksums - why
> checksum in software, when in theory the drive + controllers should do
> it anyway ;)
>
> Regards, Clemens
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
It would certainly be a vast improvement if flash media had some of the 
sanity checking capability that conventional media has, but to say that 
these sorts of problems with flash media are legendary would almost be 
an understatement.

As for checksums, I view them more as a tool to detect data decay as 
opposed to checking for failed writes.  Of course that data decay might 
well result in failed writes when btrfs scrub tries to correct it.  At 
that point I would prefer that the drive, even flash media type, would 
catch and resolve write failures.  If it doesn't happen at the hardware 
layer, according to how I understand Hugo's answer, btrfs, at least for 
now, is not capable of it.  I believe it is true that filesystems 
historically done bad blocking, but I do think it is moving now to the 
hardware layer which is probably the best place for it to be and the 
flash drive industry needs to solve this problem at the 
hardware/firmware level.  That is my opinion anyway.

  reply	other threads:[~2014-01-10  0:46 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 10:26 How does btrfs handle bad blocks in raid1? Clemens Eisserer
2014-01-09 10:42 ` Hugo Mills
2014-01-09 12:41   ` Duncan
2014-01-09 12:52     ` Austin S Hemmelgarn
2014-01-09 15:15       ` Duncan
2014-01-09 16:49         ` George Eleftheriou
2014-01-09 17:09           ` Hugo Mills
2014-01-09 17:34             ` George Eleftheriou
2014-01-09 17:43               ` Hugo Mills
2014-01-09 18:40                 ` George Eleftheriou
2014-01-09 17:29           ` Chris Murphy
2014-01-09 18:00             ` George Eleftheriou
2014-01-10 15:27           ` Duncan
2014-01-10 15:46             ` George Mitchell
2014-01-09 17:31       ` Chris Murphy
2014-01-09 18:20         ` Austin S Hemmelgarn
2014-01-09 14:58     ` Chris Mason
2014-01-09 18:08     ` Chris Murphy
2014-01-09 18:22       ` Austin S Hemmelgarn
2014-01-09 18:52         ` Chris Murphy
2014-01-10 17:03           ` Duncan
2014-01-09 18:40   ` Chris Murphy
2014-01-09 19:13     ` Kyle Gates
2014-01-09 19:31       ` Chris Murphy
2014-01-09 23:24         ` George Mitchell
2014-01-10  0:08           ` Clemens Eisserer
2014-01-10  0:46             ` George Mitchell [this message]
     [not found] <201401100106.s0A16CNd016476@atl4mhib27.myregisteredsite.com>
2014-01-10  1:31 ` George Mitchell
2014-01-14 19:13   ` Chris Murphy
2014-01-14 19:37     ` Roman Mamedov
2014-01-14 21:05       ` Chris Murphy
2014-01-14 21:19         ` Roman Mamedov
2014-01-14 21:37           ` Chris Murphy
2014-01-14 21:45             ` Chris Murphy
2014-01-14 21:54             ` Roman Mamedov
2014-01-14 20:29     ` George Mitchell
2014-01-14 21:00       ` Roman Mamedov
2014-01-14 21:06         ` Hugo Mills
2014-01-14 21:27           ` Chris Murphy
2014-01-14 21:27         ` George Mitchell
2014-01-14 21:28         ` George Mitchell
2014-01-14 21:14       ` Chris Murphy
2014-01-14 21:48         ` George Mitchell
2014-01-14 21:48         ` George Mitchell
2014-01-14 22:14         ` George Mitchell

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=52CF4302.6020403@chinilu.com \
    --to=george@chinilu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linuxhippy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.