From: Bill Davidsen <davidsen@tmr.com>
To: Doug Ledford <dledford@redhat.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>,
Jon Nelson <jnelson-linux-raid@jamponi.net>,
linux-raid@vger.kernel.org
Subject: Re: [ANNOUNCE] mdadm-3.1 has been withdrawn
Date: Thu, 12 Nov 2009 17:25:49 -0500 [thread overview]
Message-ID: <4AFC8B6D.7080603@tmr.com> (raw)
In-Reply-To: <4AF8847D.8030303@redhat.com>
Doug Ledford wrote:
> On 11/09/2009 11:51 AM, Mikael Abrahamsson wrote:
>
>> On Mon, 9 Nov 2009, Jon Nelson wrote:
>>
>>
>>> I've been using 1.1 for everything. What's the current wisdom
>>> regarding 1.0 vs 1.1 or 1.2?
>>> I used 1.1 because that's also where filesystem metadata usually goes
>>> and therefore one might hope that the presence of the md metadata
>>> would prevent accidental identification of a raid volume as containing
>>> a filesystem.
>>>
>> I like 1.2 because if you happen to write an MBR or something to the
>> drive, you don't lose the superblock.
>>
>
> Of course, I recently had a bug report that I ended closing out as
> NOTABUG because of this very ability. The person had arrays with 1.2
> superblocks, and they went to add a new disk, and all the existing disks
> had a specific partition layout, so he copied that to the new disk, then
> tried to add the partition to the raid array. It kept returning "device
> too small for array". Then, upon inspection, we come to see he has a
> 1.2 superblock on the *entire* drive, which left the partition table
> intact, but the partition table is *pointless* because the array is on
> the whole disk devices. This sort of confusion is bad. So, while I
> could see making it 1.2 for partitions (so that boot sectors won't
> overwrite the superblock), I wouldn't make it 1.2 for whole disk
> devices, and in fact it might be wise to refuse to create 1.2
> superblocks on whole disk devices. Just a thought.
>
>
I'm trying to wrap my head around this recommendation, and not doing
well. The end of the allocation area (partition, disk, array, whatever)
seems to be what users hit when they do a dd or some similar operation
without understanding it. And the from end is what they hit when they
"fix" the MBR or add a partition table because something said it was
missing. As for your friend, nothing is foolproof, and unless he tried
very hard he probably failed to damage anything in a way which couldn't
be readily fixed.
I like 1.2, I feel it's least likely to suffer collateral damage, and
the problems it causes seem to result in the type of behavior you
mention aboue, the system says "Can't, won't, you don't know what you're
doing."
--
Bill Davidsen <davidsen@tmr.com>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein
next prev parent reply other threads:[~2009-11-12 22:25 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 [this message]
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
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=4AFC8B6D.7080603@tmr.com \
--to=davidsen@tmr.com \
--cc=dledford@redhat.com \
--cc=jnelson-linux-raid@jamponi.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).