From: Adam Goryachev <mailinglists@websitemanagers.com.au>
To: Mikael Abrahamsson <swmike@swm.pp.se>,
David Brown <david.brown@hesbynett.no>
Cc: linux-raid@vger.kernel.org
Subject: Re: Paranoid mode for RAID-1 ?
Date: Mon, 27 Apr 2015 18:18:57 +1000 [thread overview]
Message-ID: <553DF0F1.8060608@websitemanagers.com.au> (raw)
In-Reply-To: <alpine.DEB.2.02.1504270925480.16871@uplift.swm.pp.se>
On 27/04/15 17:35, Mikael Abrahamsson wrote:
> On Mon, 27 Apr 2015, David Brown wrote:
>
>> btrfs has data checksums like that. Like Neil, I question the
>> necessity for harddisks, but such checksums are lower cost than
>> reading the data twice from two disks (as they are stored as part of
>> the metadata that you already read), and can offer some protection
>> against serious hardware problems. (Checksums like this cannot
>> easily be implemented in a transparent block device such as md raid -
>> it is more practical to have them as part of the filesystem, as done
>> with btrfs.)
>
> Only way I can imagine this being done would be for instance to add a
> 4KiB block for every 128KiB chunk or something like that, and perhaps
> have a smaller checksum for each 4KiB block within that 128KiB chunk.
>
> I doubt anyone would be interested in putting efforts into creating
> this though as it would have "interesting" performance drawbacks, and
> that work is probably better spent by making sure that btrfs and/or
> zfs gets more development/testing than it is to put that effort into
> md. I personally prefer md to be fairly "simple" so we have as few
> bugs as possible in it, I'd say that md generally works and the number
> of developers working heroically on its current incarnation is barely
> enough to make sure that the codebase works as well as it must
> considering the critical function it serves for a lot of us.
>
> This has been discussed before and nobody has shown interest in
> actually developing code for it, so we're still at the feature request
> and "brainstorming about design" state, and without actual coder(s)
> willing to actually implement, it's not going to get further than this
> stage.
>
Speaking of which, I'm not convinced that we should spend that developer
time on each and every FS (eg, duplicated effort for btrfs, zfs, and any
others that do the same). It also means you must remove MD Raid, to
allow the FS to directly access each of the underlying devices.
Obviously, there are advantages in both methods.
As you and others said, without someone willing to implement/write this
feature, then it isn't going to happen.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
next prev parent reply other threads:[~2015-04-27 8:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1610581828.22506051.1430116628556.JavaMail.zimbra@laposte.net>
2015-04-27 6:37 ` Paranoid mode for RAID-1 ? Jean-Baptiste Thomas
2015-04-27 6:48 ` Adam Goryachev
2015-04-27 7:15 ` David Brown
2015-04-27 7:35 ` Mikael Abrahamsson
2015-04-27 8:18 ` Adam Goryachev [this message]
2015-04-27 8:34 ` Paranoid mode for RAID-1 ? MD-RAID checksums Pasi Kärkkäinen
2015-04-27 9:15 ` Paranoid mode for RAID-1 ? Roman Mamedov
2015-04-27 6:49 ` NeilBrown
2015-04-27 10:52 ` Jean-Baptiste Thomas
2015-04-27 16:15 ` Wols Lists
2015-04-27 8:45 ` Pieter De Wit
2015-04-27 10:18 ` <DKIM> " Jean-Baptiste Thomas
2015-04-27 10:54 ` David Brown
2015-04-27 12:36 ` Jean-Baptiste Thomas
2015-04-27 13:46 ` David Brown
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=553DF0F1.8060608@websitemanagers.com.au \
--to=mailinglists@websitemanagers.com.au \
--cc=david.brown@hesbynett.no \
--cc=linux-raid@vger.kernel.org \
--cc=swmike@swm.pp.se \
/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.