From: Dark Penguin <darkpenguin@yandex.ru>
To: Phil Turmel <philip@turmel.org>,
Andreas Klauer <Andreas.Klauer@metamorpher.de>,
Rudy Zijlstra <rudy@grumpydevil.homelinux.org>,
keld@keldix.com
Cc: linux-raid@vger.kernel.org
Subject: Re: Why not just return an error?
Date: Fri, 7 Oct 2016 20:44:37 +0300 [thread overview]
Message-ID: <57F7DF05.8090605@yandex.ru> (raw)
In-Reply-To: <94b1a4f4-adec-90b7-e804-2d8d2c94a7af@turmel.org>
On 07/10/16 19:52, Phil Turmel wrote:
> Hi DP,
>
> {It's good that you are trimming replies, but don't cut the ID of who
> wrote what. }
Oh, yeah, sorry.
> You want to push the failure condition from being "broken raid with
> likely salvageable data, except for one sector" to "repeated errors to
> the upper layers with unknowable corruption as side effects".
That actually describes it pretty well, yes. %) Being able to choose a
failure condition most suitable for your specific situation, and being
able to push it that far and still have a working RAID if you want that.
> Then patch your kernel with your desired behavior. "Free software"
> doesn't mean someone writes what you want for free. And I disagree with
> you, so would object to it being put in the mainline kernel.
Yes, that's one of the things on my TODO list once I become a developer
able to do that. :) I just thought I'm probably not the only one who
wants that, and so I wanted to learn why is it not possible. And listen
to what other people really think about it.
>> Anyway, if I had a collapsed RAID-5, I would want to at least have an
>> easy option to start it in a read-only mode in the last-known working
>> state, while the faulty drives are still not out of sync, and recover
>> data easily (to my single backup drive), or continue using the array for
>> a while, manually deleting one "bad" file if necessary; this is of
>> course not a "good thing" to do, but this way, RAID would be at least
>> not worse than single drives with faulty sectors, which are capable of
>> that, while RAIDs are not! I would be fine with that in my archive - as
>> I'm fine with some less importand parts of the archive being on faulty
>> single drives. It's just that I don't want to lose the whole drive due
>> to a hardware failure - and RAID adds more causes other than that,
>> instead of offering more protection against that.
>
> MD raid has no idea what is at any given sector. And with a
> near-infinite variety of layering choices, there's no way it's going to.
> That's why *you* have to do this. You trimmed my description of the
> only "easy option" actually trustable.
I actually wanted to ask about that. Can you really ddrescue a drive
with a "hole" in it, re-add it and expect it to work?.. What happens if
you try to read from that "hole" again? And while I'm talking about
re-adding, when does it become impossible to "re-add" a drive?..
--
darkpenguin
next prev parent reply other threads:[~2016-10-07 17:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 23:32 Why not just return an error? Dark Penguin
2016-10-07 5:26 ` keld
2016-10-07 8:21 ` Rudy Zijlstra
2016-10-07 9:30 ` keld
2016-10-07 11:21 ` Andreas Klauer
2016-10-07 14:43 ` Phil Turmel
2016-10-07 16:23 ` Dark Penguin
2016-10-07 16:52 ` Phil Turmel
2016-10-07 17:44 ` Dark Penguin [this message]
2016-10-07 18:41 ` Phil Turmel
2016-10-07 20:39 ` Dark Penguin
2016-10-07 23:11 ` Edward Kuns
2016-10-10 20:47 ` Anthony Youngman
2016-10-10 21:37 ` Andreas Klauer
2016-10-10 21:55 ` Wols Lists
2016-10-11 4:00 ` Brad Campbell
2016-10-11 9:18 ` Wols Lists
2016-10-11 10:01 ` Brad Campbell
2016-10-11 10:15 ` Wols Lists
2016-10-10 22:10 ` Wakko Warner
2016-10-07 14:19 ` Phil Turmel
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=57F7DF05.8090605@yandex.ru \
--to=darkpenguin@yandex.ru \
--cc=Andreas.Klauer@metamorpher.de \
--cc=keld@keldix.com \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.org \
--cc=rudy@grumpydevil.homelinux.org \
/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.