[PATCH] Use new sb type

[PATCH] Use new sb type

[Jan Engelhardt]

This makes 1.0 the default sb type for new arrays.

Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>

---
 Create.c |    6 ------
 super0.c |    4 +---
 super1.c |    2 +-
 3 files changed, 2 insertions(+), 10 deletions(-)

Index: mdadm-2.6.4/Create.c
===================================================================
--- mdadm-2.6.4.orig/Create.c
+++ mdadm-2.6.4/Create.c
@@ -241,12 +241,6 @@ int Create(struct supertype *st, char *m
 				fprintf(stderr, Name ": internal error - no default metadata style\n");
 				exit(2);
 			}
-			if (st->ss->major != 0 ||
-			    st->minor_version != 90)
-				fprintf(stderr, Name ": Defaulting to version"
-					" %d.%d metadata\n",
-					st->ss->major,
-					st->minor_version);
 		}
 		freesize = st->ss->avail_size(st, ldsize >> 9);
 		if (freesize == 0) {
Index: mdadm-2.6.4/super0.c
===================================================================
--- mdadm-2.6.4.orig/super0.c
+++ mdadm-2.6.4/super0.c
@@ -820,9 +820,7 @@ static struct supertype *match_metadata_
 	st->minor_version = 90;
 	st->max_devs = MD_SB_DISKS;
 	if (strcmp(arg, "0") == 0 ||
-	    strcmp(arg, "0.90") == 0 ||
-	    strcmp(arg, "default") == 0
-		)
+	    strcmp(arg, "0.90") == 0)
 		return st;
 
 	st->minor_version = 9; /* flag for 'byte-swapped' */
Index: mdadm-2.6.4/super1.c
===================================================================
--- mdadm-2.6.4.orig/super1.c
+++ mdadm-2.6.4/super1.c
@@ -1143,7 +1143,7 @@ static struct supertype *match_metadata_
 
 	st->ss = &super1;
 	st->max_devs = 384;
-	if (strcmp(arg, "1.0") == 0) {
+	if (strcmp(arg, "1.0") == 0 || strcmp(arg, "default") == 0) {
 		st->minor_version = 0;
 		return st;
 	}

Re: [PATCH] Use new sb type

[David Greaves]

Jan Engelhardt wrote:
> This makes 1.0 the default sb type for new arrays.
> 

IIRC there was a discussion a while back on renaming mdadm options (google "Time
to  deprecate old RAID formats?") and the superblocks to emphasise the location
and data structure. Would it be good to introduce the new names at the same time
as changing the default format/on-disk-location?

David

Re: [PATCH] Use new sb type

[Peter Rabbitson]

David Greaves wrote:
> Jan Engelhardt wrote:
>> This makes 1.0 the default sb type for new arrays.
>>
> 
> IIRC there was a discussion a while back on renaming mdadm options (google "Time
> to  deprecate old RAID formats?") and the superblocks to emphasise the location
> and data structure. Would it be good to introduce the new names at the same time
> as changing the default format/on-disk-location?
> 
> David

Also wasn't the concession to make 1.1 default instead of 1.0 ?

Peter

Re: [PATCH] Use new sb type

[Jan Engelhardt]

On Jan 28 2008 18:19, David Greaves wrote:
>Jan Engelhardt wrote:
>> This makes 1.0 the default sb type for new arrays.
>> 
>
>IIRC there was a discussion a while back on renaming mdadm options
>(google "Time to deprecate old RAID formats?") and the superblocks
>to emphasise the location and data structure. Would it be good to
>introduce the new names at the same time as changing the default
>format/on-disk-location?

The -e 1.0/1.1/1.2 is sufficient for me, I would not need
--metadata 1 --metadata-layout XXX.

So renaming options should definitely be a separate patch.

Re: [PATCH] Use new sb type

[David Greaves]

Peter Rabbitson wrote:
> David Greaves wrote:
>> Jan Engelhardt wrote:
>>> This makes 1.0 the default sb type for new arrays.
>>>
>>
>> IIRC there was a discussion a while back on renaming mdadm options
>> (google "Time
>> to  deprecate old RAID formats?") and the superblocks to emphasise the
>> location
>> and data structure. Would it be good to introduce the new names at the
>> same time
>> as changing the default format/on-disk-location?
>>
>> David
> 
> Also wasn't the concession to make 1.1 default instead of 1.0 ?
> 
IIRC Doug Leford did some digging wrt lilo + grub and found that 1.1 and 1.2
wouldn't work with them. I'd have to review the thread though...

David

Re: [PATCH] Use new sb type

[Tim Southerwood]

David Greaves wrote:
> Peter Rabbitson wrote:
>> David Greaves wrote:
>>> Jan Engelhardt wrote:
>>>> This makes 1.0 the default sb type for new arrays.
>>>>
>>> IIRC there was a discussion a while back on renaming mdadm options
>>> (google "Time
>>> to  deprecate old RAID formats?") and the superblocks to emphasise the
>>> location
>>> and data structure. Would it be good to introduce the new names at the
>>> same time
>>> as changing the default format/on-disk-location?
>>>
>>> David
>> Also wasn't the concession to make 1.1 default instead of 1.0 ?
>>
> IIRC Doug Leford did some digging wrt lilo + grub and found that 1.1 and 1.2
> wouldn't work with them. I'd have to review the thread though...
> 
> David
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

For what it's worth, that was my finding too. -e 0.9+1.0 are fine with
GRUB, but  1.1 an 1.2 won't work under the filesystem that contains
/boot, at least with GRUB 1.x (I haven't used LILO for some time nor
have I tried the development GRUB 2).

The reason IIRC boils down to the fact that GRUB 1 isn't MD aware, and
the only reason one can "get away" with using it on a RAID 1 setup at
all is that the constituent devices present the same data as the
composite MD device, from the start.

Putting an MD SB at/near the beginning of the device breaks this case
and GRUB 1 doesn't know how to deal with it.

Cheers
Tim

Re: [PATCH] Use new sb type

[Peter Rabbitson]

Tim Southerwood wrote:
> David Greaves wrote:
>>
>> IIRC Doug Leford did some digging wrt lilo + grub and found that 1.1 and 1.2
>> wouldn't work with them. I'd have to review the thread though...
>>
>> David
>> -
> 
> For what it's worth, that was my finding too. -e 0.9+1.0 are fine with
> GRUB, but  1.1 an 1.2 won't work under the filesystem that contains
> /boot, at least with GRUB 1.x (I haven't used LILO for some time nor
> have I tried the development GRUB 2).
> 
> The reason IIRC boils down to the fact that GRUB 1 isn't MD aware, and
> the only reason one can "get away" with using it on a RAID 1 setup at
> all is that the constituent devices present the same data as the
> composite MD device, from the start.
> 
> Putting an MD SB at/near the beginning of the device breaks this case
> and GRUB 1 doesn't know how to deal with it.
> 
> Cheers
> Tim
> -

I read the entire thread, and it seems that the discussion drifted away from 
the issue at hand. I hate flogging a dead horse, but here are my 2 cents:

First the summary:

* Currently LILO and GRUB are the only booting mechanisms widely available 
(GRUB2 is nowhere to be seen, and seems to be badly designed anyway)

* Both of these boot mechanisms do not understand RAID at all, so they can 
boot only off a block device containing a hackishly-readable filesystem (lilo: 
files are mappable, grub: a stage1.5 exists)

* The only raid level providing unfettered access to the underlying filesystem 
is RAID1 with a superblock at its end, and it has been common wisdom for years 
that you need RAID1 boot partition in order to boot anything at all.

The problem is that these three points do not affect any other raid level (as 
you can not boot from any of them in a reliable fashion anyway). I saw a 
number of voices that backward compatibility must be preserved. I don't see 
any need for that because:

* The distro managers will definitely RTM and will adjust their flashy GUIs to 
do the right thing by explicitly supplying -e 1.0 for boot devices

* A clueless user might burn himself by making a single root on a single raid1 
device. But wait - he can burn himself the same way by making the root a raid5 
device and rebooting.

Why do we sacrifice "the right thing to do"? To eliminate the possibility of 
someone shooting himself in the foot by not reading the manual?

Cheers
Peter

Yes, but please provide the clue (was Re: [PATCH] Use new sb type)

[Moshe Yudkowsky]

> * The only raid level providing unfettered access to the underlying 
> filesystem is RAID1 with a superblock at its end, and it has been common 
> wisdom for years that you need RAID1 boot partition in order to boot 
> anything at all.

Ah. This shines light on my problem...

> The problem is that these three points do not affect any other raid 
> level (as you can not boot from any of them in a reliable fashion 
> anyway). I saw a number of voices that backward compatibility must be 
> preserved. I don't see any need for that because:
> 
> * The distro managers will definitely RTM and will adjust their flashy 
> GUIs to do the right thing by explicitly supplying -e 1.0 for boot devices

The Debian stable distro won't let you create /boot on an LVM RAID1, but 
that seems to be the extent of current RAID awareness. Using the GUI, if 
you create a large RAID5 and attempt to boot off it  -- well, you're 
toast, but you don't find out until LILO and grub portion of the 
installation fails.

> * A clueless user might burn himself by making a single root on a single 
> raid1 device. But wait - he can burn himself the same way by making the 
> root a raid5 device and rebooting.

Okay, but:

> Why do we sacrifice "the right thing to do"? To eliminate the 
> possibility of someone shooting himself in the foot by not reading the 
> manual?

Speaking for clueless users everywhere: I'd love to Read The Fine 
Manual, but the Fine md, mdadm, and mdadm.conf Manuals that I've read 
don't have information about grub/LILO issues. A hint such as "grub and 
LILO can only work from RAID 1 and superblocks greater than 1.0 will 
toast your system in any case" is crucial information to have. Not 
everyone will catch this particular thread -- they're going to RTFM and 
make a mistake *regardless*.

And now, please excuse me while I RTFM to find out if I change the 
superblocks to 1.0 from 1.2 on a running array...

-- 
Moshe Yudkowsky * moshe@pobox.com * www.pobox.com/~moshe
  "If you're not part of the solution, you're part of the process."
    				-- Mark A. Johnson

Re: [PATCH] Use new sb type

[Bill Davidsen]

David Greaves wrote:
> Jan Engelhardt wrote:
>   
>> This makes 1.0 the default sb type for new arrays.
>>
>>     
>
> IIRC there was a discussion a while back on renaming mdadm options (google "Time
> to  deprecate old RAID formats?") and the superblocks to emphasise the location
> and data structure. Would it be good to introduce the new names at the same time
> as changing the default format/on-disk-location?
>   

Yes, I suggested some layout names, as did a few other people, and a few 
changes to separate metadata type and position were discussed. BUT, 
changing the default layout, no matter how "better" it seems, is trumped 
by "breaks existing setups and user practice." For all of the reasons 
something else is preferable, 1.0 *works*.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 

Re: [PATCH] Use new sb type

[David Greaves]

Bill Davidsen wrote:
> David Greaves wrote:
>> Jan Engelhardt wrote:
>>  
>>> This makes 1.0 the default sb type for new arrays.
>>>
>>>     
>>
>> IIRC there was a discussion a while back on renaming mdadm options
>> (google "Time
>> to  deprecate old RAID formats?") and the superblocks to emphasise the
>> location
>> and data structure. Would it be good to introduce the new names at the
>> same time
>> as changing the default format/on-disk-location?
>>   
> 
> Yes, I suggested some layout names, as did a few other people, and a few
> changes to separate metadata type and position were discussed. BUT,
> changing the default layout, no matter how "better" it seems, is trumped
> by "breaks existing setups and user practice." For all of the reasons
> something else is preferable, 1.0 *works*.

It wasn't my intention to change anything other than the naming.

If the default layout was being updated to 1.0 then I thought it would be a good
time to introduce 1-start, 1-4k and 1-end names and actually announce a default
of "1-end" and not "1.0".

Although I still prefer a full separation:
  mdadm --create /dev/md0 --metadata 1 --meta-location start

David

Re: [PATCH] Use new sb type

[Jan Engelhardt]

On Jan 29 2008 18:08, Bill Davidsen wrote:

>> IIRC there was a discussion a while back on renaming mdadm options
>> (google "Time to deprecate old RAID formats?") and the superblocks
>> to emphasise the location and data structure. Would it be good to
>> introduce the new names at the same time as changing the default
>> format/on-disk-location?
>
> Yes, I suggested some layout names, as did a few other people, and
> a few changes to separate metadata type and position were
> discussed. BUT, changing the default layout, no matter how "better"
> it seems, is trumped by "breaks existing setups and user practice."

Layout names are a different matter from what the default sb type should 
be.

Re: [PATCH] Use new sb type

[David Greaves]

Jan Engelhardt wrote:
> On Jan 29 2008 18:08, Bill Davidsen wrote:
> 
>>> IIRC there was a discussion a while back on renaming mdadm options
>>> (google "Time to deprecate old RAID formats?") and the superblocks
>>> to emphasise the location and data structure. Would it be good to
>>> introduce the new names at the same time as changing the default
>>> format/on-disk-location?
>> Yes, I suggested some layout names, as did a few other people, and
>> a few changes to separate metadata type and position were
>> discussed. BUT, changing the default layout, no matter how "better"
>> it seems, is trumped by "breaks existing setups and user practice."
> 
> Layout names are a different matter from what the default sb type should 
> be.
Indeed they are. Or rather should be.

However the current default sb includes a layout element. If the default sb is
changed then it seems like an opportunity to detach the data format from the
on-disk location.

David

Re: [PATCH] Use new sb type

[Jan Engelhardt]

On Feb 10 2008 10:34, David Greaves wrote:
>Jan Engelhardt wrote:
>> On Jan 29 2008 18:08, Bill Davidsen wrote:
>> 
>>>> IIRC there was a discussion a while back on renaming mdadm options
>>>> (google "Time to deprecate old RAID formats?") and the superblocks
>>>> to emphasise the location and data structure. Would it be good to
>>>> introduce the new names at the same time as changing the default
>>>> format/on-disk-location?
>>> Yes, I suggested some layout names, as did a few other people, and
>>> a few changes to separate metadata type and position were
>>> discussed. BUT, changing the default layout, no matter how "better"
>>> it seems, is trumped by "breaks existing setups and user practice."
>> 
>> Layout names are a different matter from what the default sb type should 
>> be.
>Indeed they are. Or rather should be.
>
>However the current default sb includes a layout element. If the default sb is
>changed then it seems like an opportunity to detach the data format from the
>on-disk location.

I do not see anything wrong by specifying the SB location as a metadata
version. Why should not location be an element of the raid type?
It's fine the way it is IMHO. (Just the default is not :)

Re: [PATCH] Use new sb type

[David Greaves]

Jan Engelhardt wrote:
> On Feb 10 2008 10:34, David Greaves wrote:
>> Jan Engelhardt wrote:
>>> On Jan 29 2008 18:08, Bill Davidsen wrote:
>>>
>>>>> IIRC there was a discussion a while back on renaming mdadm options
>>>>> (google "Time to deprecate old RAID formats?") and the superblocks
>>>>> to emphasise the location and data structure. Would it be good to
>>>>> introduce the new names at the same time as changing the default
>>>>> format/on-disk-location?
>>>> Yes, I suggested some layout names, as did a few other people, and
>>>> a few changes to separate metadata type and position were
>>>> discussed. BUT, changing the default layout, no matter how "better"
>>>> it seems, is trumped by "breaks existing setups and user practice."
>>> Layout names are a different matter from what the default sb type should 
>>> be.
>> Indeed they are. Or rather should be.
>>
>> However the current default sb includes a layout element. If the default sb is
>> changed then it seems like an opportunity to detach the data format from the
>> on-disk location.
> 
> I do not see anything wrong by specifying the SB location as a metadata
> version. Why should not location be an element of the raid type?
> It's fine the way it is IMHO. (Just the default is not :)

There was quite a discussion about it.

For me the main argument is that for most people seeing superblock versions
(even the manpage terminology is version and subversion) will correlate
incremental versions with improvement.
They will therefore see v1.2 as 'the latest and best'.
We had our first 'in the wild' example just a few days ago.

Feel free to argue that the manpage is clear on this - but as we know, not
everyone reads the manpages in depth...

It's misleading and I would submit that *if* Neil decides to change the default
then changing the terminology at the same time would mean a single change that
ushers in broader benefit.

I acknowledge that I am only talking semantics - OTOH I think semantics can be a
very important aspect of communication.

David
PS I would love to send a patch to mdadm in - I am currently being heavily
nagged to sort out our house electrics and get lunch. It may happen though :)

Re: [PATCH] Use new sb type

[Jan Engelhardt]

On Feb 10 2008 12:27, David Greaves wrote:
>> 
>> I do not see anything wrong by specifying the SB location as a metadata
>> version. Why should not location be an element of the raid type?
>> It's fine the way it is IMHO. (Just the default is not :)
>
>There was quite a discussion about it.
>
>For me the main argument is that for most people seeing superblock versions
>(even the manpage terminology is version and subversion) will correlate
>incremental versions with improvement.
>They will therefore see v1.2 as 'the latest and best'.
>Feel free to argue that the manpage is clear on this - but as we know, not
>everyone reads the manpages in depth...

That is indeed suboptimal (but I would not care since I know the
implications of an SB at the front);

Naming it "1@front" / "1@back" / "1@4K" or so would address this.

Re: [PATCH] Use new sb type

[Bill Davidsen]

Jan Engelhardt wrote:
> On Feb 10 2008 12:27, David Greaves wrote:
>   
>>> I do not see anything wrong by specifying the SB location as a metadata
>>> version. Why should not location be an element of the raid type?
>>> It's fine the way it is IMHO. (Just the default is not :)
>>>       
>> There was quite a discussion about it.
>>
>> For me the main argument is that for most people seeing superblock versions
>> (even the manpage terminology is version and subversion) will correlate
>> incremental versions with improvement.
>> They will therefore see v1.2 as 'the latest and best'.
>> Feel free to argue that the manpage is clear on this - but as we know, not
>> everyone reads the manpages in depth...
>>     
>
> That is indeed suboptimal (but I would not care since I know the
> implications of an SB at the front);
>
> Naming it "1@front" / "1@back" / "1@4K" or so would address this.
>
>   
We have already discussed names and Neil has expressed satisfaction with 
my earlier suggestion. Since "@" is sort of a semi-special character to 
the shell, I suspect we are better off avoiding it.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 

Re: [PATCH] Use new sb type

[David Greaves]

Jan Engelhardt wrote:
>> Feel free to argue that the manpage is clear on this - but as we know, not
>> everyone reads the manpages in depth...
> 
> That is indeed suboptimal (but I would not care since I know the
> implications of an SB at the front)

Neil cares even less and probably  doesn't even need mdadm - heck he probably
just echos the raw superblock into place via dd...

http://xkcd.com/378/

:D

David

Re: [PATCH] Use new sb type

[Bill Davidsen]

David Greaves wrote:
> Jan Engelhardt wrote:
>   
>>> Feel free to argue that the manpage is clear on this - but as we know, not
>>> everyone reads the manpages in depth...
>>>       
>> That is indeed suboptimal (but I would not care since I know the
>> implications of an SB at the front)
>>     
>
> Neil cares even less and probably  doesn't even need mdadm - heck he probably
> just echos the raw superblock into place via dd...
>
> http://xkcd.com/378/
>   

I don't know why this makes me think of APL...

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark