From: Hubert Kario <hka@qbs.com.pl>
To: cwillu <cwillu@cwillu.com>
Cc: "Fajar A. Nugraha" <list@fajar.net>,
Clemens Eisserer <linuxhippy@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Can btrfs silently repair read-error in raid1
Date: Tue, 08 May 2012 23:47:11 +0200 [thread overview]
Message-ID: <2557067.fSI13aCqDU@bursa22> (raw)
In-Reply-To: <CAE5mzvg8HgZPgFmNB3ZeuJTfLtrfeXH417bEVuHFST5z=zOMFw@mail.gmail.com>
On Tuesday 08 of May 2012 04:45:51 cwillu wrote:
> On Tue, May 8, 2012 at 1:36 AM, Fajar A. Nugraha <list@fajar.net> wro=
te:
> > On Tue, May 8, 2012 at 2:13 PM, Clemens Eisserer <linuxhippy@gmail.=
com>=20
wrote:
> >> Hi,
> >>=20
> >> I have a quite unreliable SSD here which develops some bad blocks =
from
> >> time to time which result in read-errors.
> >> Once the block is written to again, its remapped internally and
> >> everything is fine again for that block.
> >>=20
> >> Would it be possible to create 2 btrfs partitions on that drive an=
d
> >> use it in RAID1 - with btrfs silently repairing read-errors when t=
hey
> >> occur?
> >> Would it require special settings, to not fallback to read-only mo=
de
> >> when a read-error occurs?
> >=20
> > The problem would be how the SSD (and linux) behaves when it
> > encounters bad blocks (not bad disks, which is easier).
> >=20
> > If it does "oh, I can't read this block. I just return an error
> > immediately", then it's good.
> >=20
> > However, in most situation, it would be like "hmmm, I can't read th=
is
> > block, let me retry that again. What? still error? then lets retry =
it
> > again, and again.", which could take several minutes for a single b=
ad
> > block. And during that time linux (the kernel) would do something l=
ike
> > "hey, the disk is not responding. Why don't we try some stuff? Let'=
s
> > try resetting the link. If it doesn't work, try downgrading the lin=
k
> > speed".
> >=20
> > In short, if you KNOW the SSD is already showing signs of bad block=
s,
> > better just throw it away.
>=20
> The excessive number of retries (basically, the kernel repeating the
> work the drive already attempted) is being addressed in the block
> layer.
>=20
> "[PATCH] libata-eh don't waste time retrying media errors (v3)", I
> believe this is queued for 3.5
I just hope they don't remove retries completely, I've seen the second =
or=20
third try return correct data on multiple disks from different vendors.=
=20
(Which allowed me to use dd to write the data back to force relocation)
But yes, Linux is a bit too overzelous with regards to retries...
Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
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
next prev parent reply other threads:[~2012-05-08 21:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-08 7:13 Can btrfs silently repair read-error in raid1 Clemens Eisserer
2012-05-08 7:26 ` Jan Schmidt
2012-05-08 7:36 ` Fajar A. Nugraha
2012-05-08 10:45 ` cwillu
2012-05-08 21:47 ` Hubert Kario [this message]
2012-05-09 11:08 ` Atila
2012-05-08 23:34 ` Chris Samuel
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=2557067.fSI13aCqDU@bursa22 \
--to=hka@qbs.com.pl \
--cc=cwillu@cwillu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linuxhippy@gmail.com \
--cc=list@fajar.net \
/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.