From: Doug Ledford <dledford@redhat.com>
To: Neil F Brown <nfbrown@novell.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [ANNOUNCE] mdadm-3.1 has been withdrawn
Date: Mon, 09 Nov 2009 16:00:07 -0500 [thread overview]
Message-ID: <4AF882D7.4030503@redhat.com> (raw)
In-Reply-To: <423765b7af1be77f0a40dcbbb1f65c4b.squirrel@neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
On 11/09/2009 03:22 PM, Neil F Brown wrote:
> On Tue, November 10, 2009 1:39 am, Doug Ledford wrote:
>> On 11/06/2009 01:45 AM, Neil Brown wrote:
>>>
>>> Greetings.
>>>
>>> About a week ago I released mdadm-3.1
>>> I have now 'withdrawn' it meaning that it doesn't appear on the
>>> kernel.org mirrors any more, and I ask people not to use it.
>>
>> Although the cause for this sucks, I was actually going to suggest that
>> since 3.1 is a version bump, that we take the opportunity to change a
>> few defaults. Like switching to version 1 superblocks instead of
>> version 0 by default. And changing the default chunk size to 512k
>> instead of 64k. The time has simply come for the 0->1 superblock
>> change, and I have a good deal of data showing that for SATA disks at
>> least, the 512k chunk size is the typical sweet spot.
>
> I had been toying with that idea myself - certainly of changing the
> defaults soon.
> I'm tempted to make the default metadata "1.1" though possibly not for
> RAID1. For RAID0,4,5,6,10 there is no value in having the metadata
> at the end of the device. For RAID1 there is as it makes booting off
> any member easier.
> Thoughts?
While it makes booting off of a raid1 easier, raid1 is *precisely* the
level that is prone to silent data corrupt due to the individual members
being able to be mounted while not part of a running raid array. I
would make it default to 1.1 period, and force distros or other people
to either A) update the boot loader to something that can handle a 1.1
superblock (grub2 should be able to) or B) manually set it to 1.0 instead.
>
> I'm certainly happy with increasing the chunksize to 512K.
>
> NeilBrown
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-11-09 21:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-06 6:45 [ANNOUNCE] mdadm-3.1 has been withdrawn Neil Brown
2009-11-09 14:39 ` Doug Ledford
2009-11-09 15:36 ` berk walker
2009-11-09 15:42 ` Jon Nelson
2009-11-09 16:51 ` Mikael Abrahamsson
2009-11-09 21:07 ` Doug Ledford
2009-11-09 21:27 ` Luca Berra
2009-11-09 21:43 ` Jon Nelson
2009-11-10 8:25 ` Mikael Abrahamsson
2009-11-10 14:22 ` Jon Nelson
2009-11-11 3:26 ` Michael Evans
2009-11-12 22:25 ` Bill Davidsen
2009-11-13 5:50 ` Mikael Abrahamsson
2009-11-13 13:04 ` Bill Davidsen
2009-11-09 20:22 ` Neil F Brown
2009-11-09 21:00 ` Doug Ledford [this message]
2009-11-13 23:54 ` Dan Williams
2009-11-14 3:32 ` Doug Ledford
[not found] <nfbrown@novell.com>
2009-11-12 17:51 ` greg
2009-11-12 23:02 ` Rudy Zijlstra
2009-11-13 1:53 ` Michael Evans
2009-11-13 2:02 ` Neil 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=4AF882D7.4030503@redhat.com \
--to=dledford@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=nfbrown@novell.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.