Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

[Piete Brooks]

I really love having my partitions as RAID1 devices as it allows the actual 
partition major and minor numbers to change, and allows me to "move" 
partitions by adding and removing them from the array.

As such I do this even when there is only one partition. To move it, I can 
make it a two way mirror, add the new partition, then remove the old. However, 
I can't then shrink it back to being a one way mirror. Is there a good reason 
for this, or is it just not something that was considered sane?
[ "really" just runs a command as root ]

bedat-32:~: really mdadm -Gn1 /dev/md1
mdadm: '1' is an unusual number of drives for an array, so it is probably
     a mistake.  If you really mean it you will need to specify --force before
     setting the number of drives.
bedat-32:~: really mdadm -G --force -n1 /dev/md1
mdadm: option f not valid in grow mode
bedat-32:~: really mdadm --force -Gn1 /dev/md1
mdadm: -G would set mode to grow, but it is already manage.
bedat-32:~:  mdadm -V
mdadm - v1.6.0 - 4 June 2004
bedat-32:~: rpm -q mdadm       
mdadm-1.6.0-2
bedat-32:~: 

Any ideas?

Re: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

[Peter T. Breuer]

Piete Brooks <Piete.Brooks@cl.cam.ac.uk> wrote:
> I really love having my partitions as RAID1 devices as it allows the actual 
> partition major and minor numbers to change, and allows me to "move" 
> partitions by adding and removing them from the array.

Good idea.

> As such I do this even when there is only one partition. To move it, I can 
> make it a two way mirror, add the new partition, then remove the old. However, 
I think I'd call that "copying", not moving!

> I can't then shrink it back to being a one way mirror. Is there a good reason 
> for this, or is it just not something that was considered sane?
> [ "really" just runs a command as root ]

> bedat-32:~: really mdadm -Gn1 /dev/md1
> mdadm: '1' is an unusual number of drives for an array, so it is probably
>      a mistake.  If you really mean it you will need to specify --force before
>      setting the number of drives.
> bedat-32:~: really mdadm -G --force -n1 /dev/md1
> mdadm: option f not valid in grow mode
> bedat-32:~: really mdadm --force -Gn1 /dev/md1
> mdadm: -G would set mode to grow, but it is already manage.
> bedat-32:~:  mdadm -V
> mdadm - v1.6.0 - 4 June 2004
> bedat-32:~: rpm -q mdadm       
> mdadm-1.6.0-2
> bedat-32:~: 

Well, you could always just remake the mirror with --dangerous-no-resync
using mkraid. I don't know if mdadm permits that. I would have thought
it supported the semantics in mode create or assemble or whatever, just
by virtue of the fact of making an array with one compnent. So try -C
or -A.

Peter

Re: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

[Neil Brown]

On Thursday June 9, Piete.Brooks@cl.cam.ac.uk wrote:
> I really love having my partitions as RAID1 devices as it allows the actual 
> partition major and minor numbers to change, and allows me to "move" 
> partitions by adding and removing them from the array.
> 
> As such I do this even when there is only one partition. To move it, I can 
> make it a two way mirror, add the new partition, then remove the old. However, 
> I can't then shrink it back to being a one way mirror. Is there a good reason 
> for this, or is it just not something that was considered sane?
> [ "really" just runs a command as root ]
> 
> bedat-32:~: really mdadm -Gn1 /dev/md1
> mdadm: '1' is an unusual number of drives for an array, so it is probably
>      a mistake.  If you really mean it you will need to specify --force before
>      setting the number of drives.
> bedat-32:~: really mdadm -G --force -n1 /dev/md1
> mdadm: option f not valid in grow mode

Hmmm.... yes... Didn't think of that did I?

I'm very close to releasing mdadm 1.12.0.  It will have this fixed.

If you are impatient, the patch against 1.11.0 is very simple.  See
below.

Thanks,
NeilBrown


### Diffstat output
 ./mdadm.c |    1 +
 1 files changed, 1 insertion(+)

diff ./mdadm.c~current~ ./mdadm.c
--- ./mdadm.c~current~	2005-06-08 14:41:33.000000000 +1000
+++ ./mdadm.c	2005-06-09 21:08:40.000000000 +1000
@@ -466,6 +466,7 @@ int main(int argc, char *argv[])
 			continue;
 
 		case O(BUILD,'f'): /* force honouring '-n 1' */
+		case O(GROW,'f'): /* ditto */
 		case O(CREATE,'f'): /* force honouring of device list */
 		case O(ASSEMBLE,'f'): /* force assembly */
 		case O(MISC,'f'): /* force zero */



> bedat-32:~: really mdadm --force -Gn1 /dev/md1
> mdadm: -G would set mode to grow, but it is already manage.
> bedat-32:~:  mdadm -V
> mdadm - v1.6.0 - 4 June 2004
> bedat-32:~: rpm -q mdadm       
> mdadm-1.6.0-2
> bedat-32:~: 
> 
> Any ideas?
> 
> -
> 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

Re: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

[Luca Berra]

On Thu, Jun 09, 2005 at 09:12:02PM +1000, Neil Brown wrote:
>I'm very close to releasing mdadm 1.12.0.  It will have this fixed.

do you have a prerelease, i'd like to test the stacking stuff.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

[Piete Brooks]

> Hmmm.... yes... Didn't think of that did I?

I know the feeling :-(

> I'm very close to releasing mdadm 1.12.0.  It will have this fixed.

Thanks.

> If you are impatient, the patch against 1.11.0 is very simple.  See below.
> +		case O(GROW,'f'): /* ditto */

That was exactly the patch I applied, apart from the comment, and I put it one 
line higher :-))
( I really meant "Is there a good reason not to, as I have already done it"!)


The next thing I stumbled over was:

       When  reducing the number of devices in a RAID1 array, the slots which
       are to be removed from the array must already be vacant.

Is there a command to "move this device to another slot"? I'm stuck with:

	md8 : active raid1 sdb8[1]
	      4208896 blocks [2/1] [_U]

which I can't reduce to a one way mirror as it's in slot 1 not 0 :-((



Are you interested in problems compiling under 64b?
I fixed the first using a simple "(int)", but I'm not up enough on how what 
long long unsigned int should mean with different length words that I just 
chopped the "-Werror" so I could test it ...

gcc -Wall -Werror -Wstrict-prototypes -DCONFFILE=\"/etc/mdadm.conf\" -ggdb 
-DSendmail=\""/usr/sbin/sendmail -t"\"   -c -o bitmap.o bitmap.c
bitmap.c: In function `bitmap_fd_read':
bitmap.c:130: warning: int format, different type arg (arg 3)
bitmap.c:171: warning: long long unsigned int format, __u64 arg (arg 3)
bitmap.c: In function `ExamineBitmap':
bitmap.c:241: warning: long long unsigned int format, __u64 arg (arg 2)
bitmap.c:242: warning: long long unsigned int format, __u64 arg (arg 2)
bitmap.c:247: warning: long long unsigned int format, __u64 arg (arg 2)
make: *** [bitmap.o] Error 1

Re: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?

[Neil Brown]

On Thursday June 9, bluca@comedia.it wrote:
> On Thu, Jun 09, 2005 at 09:12:02PM +1000, Neil Brown wrote:
> >I'm very close to releasing mdadm 1.12.0.  It will have this fixed.
> 
> do you have a prerelease, i'd like to test the stacking stuff.

try:
  http://www.cse.unsw.edu.au/~neilb/source/mdadm/mdadm-test.tgz

It doesn't have an updated version number of anything, but it does try
to get --stop --scan right for stacked devices, and it does have
ChangeLog entries.
(I haven't done anything about improving the lot of --assemble for
stacked devices)

NeilBrown

> 
> L.
> 
> -- 
> Luca Berra -- bluca@comedia.it
>         Communication Media & Services S.r.l.
>  /"\
>  \ /     ASCII RIBBON CAMPAIGN
>   X        AGAINST HTML MAIL
>  / \

Stacked devices (Was: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?)

[Luca Berra]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Thu, Jun 09, 2005 at 11:18:36PM +1000, Neil Brown wrote:
>On Thursday June 9, bluca@comedia.it wrote:
>> On Thu, Jun 09, 2005 at 09:12:02PM +1000, Neil Brown wrote:
>> >I'm very close to releasing mdadm 1.12.0.  It will have this fixed.
>> 
>> do you have a prerelease, i'd like to test the stacking stuff.
>
>try:
>  http://www.cse.unsw.edu.au/~neilb/source/mdadm/mdadm-test.tgz
>
>It doesn't have an updated version number of anything, but it does try
>to get --stop --scan right for stacked devices, and it does have
thanks a lot, now stopping stacked devices work.

>(I haven't done anything about improving the lot of --assemble for
>stacked devices)

i did some investigation and found the issue that caused mdadm failing
for me with stacked device.
I am an udev user and i use the --auto flag to assemble to create the
device files.
mdadm does create a device list at the beginning and while reloading the
/proc/partitions file does not add new md devices to the device list, so
i plugged add_dev into open_mddev() and now everything seems to work
perfectly.

patch is attached.
also please add the manpage for mdassemble (also attached)

Regards,
Luca

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[-- Attachment #2: mdadm-1.11.0-auto-stacked.patch.bz2 --]
[-- Type: application/octet-stream, Size: 606 bytes --]

[-- Attachment #3: mdadm-1.11.0-mdassemble-man.patch --]
[-- Type: text/plain, Size: 1958 bytes --]

--- mdadm-1.11.0/mdassemble.8.mdassembleman	2005-05-16 21:41:08.000000000 +0200
+++ mdadm-1.11.0/mdassemble.8	2005-05-16 21:01:19.000000000 +0200
@@ -0,0 +1,59 @@
+.\" -*- nroff -*-
+.TH MDASSEMBLE 8 "" v1.11.0
+.SH NAME
+mdassemble \- assemble MD devices
+.I aka
+Linux Software Raid.
+
+.SH SYNOPSIS
+
+.BI mdassemble
+
+.SH DESCRIPTION 
+.B mdassemble
+is a tiny program that can be used to assemble MD devices inside an
+initial ramdisk (initrd) or initramfs, it is meant to replace the in-kernel
+automatic raid detection and activation.
+It can be built statically and linked against lightweight libc alternatives, like
+.B dietlibc,
+.B klibc
+or
+.B uClibc.
+
+.SH USAGE
+Invoking
+.B mdassemble
+has the same effect as invoking
+.B mdadm --assemble --scan.
+
+.SH OPTIONS
+
+There are no options to
+.B mdassemble.
+
+.SH FILES
+
+.SS /etc/mdadm.conf
+
+The config file lists which devices may be scanned to see if
+they contain MD super block, and gives identifying information
+(e.g. UUID) about known MD arrays.  See
+.BR mdadm.conf (5)
+for more details.
+
+.B mdassemble
+supports all configuration parameters defined in
+.B mdadm.conf
+with the exception of
+.B auto=
+which is supported only if mdadm was built with the 
+.B -DMDASSEMBLE_AUTO
+define.
+
+.SH SEE ALSO
+.PP
+.BR mdadm (8),
+.BR mdadm.conf (5),
+.BR md (4).
+.PP
+.BR diet (1).
--- mdadm-1.11.0/Makefile.mdassembleman	2005-04-11 02:12:32.000000000 +0200
+++ mdadm-1.11.0/Makefile	2005-05-16 21:40:56.000000000 +0200
@@ -67,7 +67,7 @@
 ASSEMBLE_FLAGS = -DMDASSEMBLE_AUTO
 endif
 
-all : mdadm mdadm.man md.man mdadm.conf.man
+all : mdadm mdadm.man md.man mdadm.conf.man mdassemble.man
 
 everything: all mdadm.static mdadm.tcc mdadm.uclibc
 
@@ -113,6 +113,9 @@
 mdadm.conf.man : mdadm.conf.5
 	nroff -man mdadm.conf.5 > mdadm.conf.man
 
+mdassemble.man : mdassemble.8
+	nroff -man mdassemble.8 > mdassemble.man
+
 $(OBJS) : mdadm.h
 
 install : mdadm mdadm.8 md.4 mdadm.conf.5

Re: Stacked devices (Was: Is there a good reason why I can't "mdadm -Gfn1 /dev/md1" ?)

[Neil Brown]

On Sunday June 12, bluca@comedia.it wrote:
> 
> i did some investigation and found the issue that caused mdadm failing
> for me with stacked device.
> I am an udev user and i use the --auto flag to assemble to create the
> device files.
> mdadm does create a device list at the beginning and while reloading the
> /proc/partitions file does not add new md devices to the device list, so
> i plugged add_dev into open_mddev() and now everything seems to work
> perfectly.

Sounds like a very sensible fix, thanks.

> also please add the manpage for mdassemble (also attached)

Yep, it will be in the next mdadm.
Thanks again.
NeilBrown