All of lore.kernel.org
 help / color / mirror / Atom feed
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 19:23:44 +0300	[thread overview]
Message-ID: <57F7CC10.3050607@yandex.ru> (raw)
In-Reply-To: <e887908f-ba51-0f88-f891-f60e8bac50bd@turmel.org>

> Likewise, when the first disk fails, one could mark it as kind of in an error state,
> and keep it running, and if one gets a read error, then you could get
> the data from the good disks.

Yes!! If a drive is "faulty", it means "you should replace it because it 
is failing"; there is no need to actually stop using it and degrade the 
whole RAID operation! What's more, it would be extremely useful at 
rebuilding without any performance loss: let the array work in degraded 
mode, while the faulty drive is being copied to the new one, with only 
read errors reconstructed from the rest of the drives! But that's a 
different issue, and not a very good idea for other reasons.


> One big reason is human behaviour. And it is human behaviour that in the
> end causes all the collapsed raids.

"Human behaviour", that's what I'm talking about. If the only reason to 
do it is to force people to do what is necessary, that approach is 
called "Windows". :) And I do not suggest that it should be the default 
behaviour; instead, we should have an option "--idiotmode 
--yes-i-know-what-i-am-doing" at RAID creation for those who 
specifically want to take the risks.

And of course, no broken files will appear if we suffer from read 
*errors*. We do not suffer from *incorrect reads*, right?..


> You make it sound like it solves all problems, but it does not.
> Errors are just not part of the concept anywhere really.

It does not "solve all problems", but it lets me solve my problems my 
way, and not "the only correct and intended way" - which is what Linux 
is good at. :)


>> > I believe this is the dream of everyone who had ever dealt with RAIDs.
>
> My dream is different. I don't want errors. I want it to work. ;)
> And it does, as long as you make sure your disks are healthy.

I do not suggest that we do it my way and not yours - we have an option 
to do it your way, but we do not have one to do it my way, that's the 
problem. :)

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.


>> > Using cosmetics to hide errors only works to a certain limit.
>> > In the end, RAID only works if the disks work. RAID 5 with
>> > two dead disks is dead, no way to get around that. Disks go bad
>> > and need to be replaced, if you don't do that, you'll just fail
>> > even more horribly later on.
>
> Concur.  We seem to differ on where to draw the line on "bad".

And I think that line should be easy to move, so that anyone could 
choose their own! I understand that RAID is meant for "uptime, not 
backups" - for enterprise production. And everything that you say is 
correct about this case. However, there are other uses - like mirroring 
my backup archive to protect against whole-drive failures. And in this 
case, I want different behaviour; I can take in onto myself to make sure 
a read error won't make my filesystems go into read-only mode and break 
anything, I really know what I'm doing, and I don't need my computer to 
tell me that RAID is not supposed to be used in this way. And it 
shouldn't add a lot of complex code - just a test "if idiotmode and 
lastdisk then return error, else kick drive; shout like crazy either 
way". :)

It's just that everyone has their own opinion on where to draw the line, 
and the "intended" one should of course be preached, but not forced!

-- 
darkpenguin

  reply	other threads:[~2016-10-07 16:23 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 [this message]
2016-10-07 16:52       ` Phil Turmel
2016-10-07 17:44         ` Dark Penguin
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=57F7CC10.3050607@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.