Re: Behavior of mdadm depending on user
On Mon, 2007-07-02 at 21:10 -0500, Michael Schwarz wrote: This ia just a couple of quick questions. I'm charged with developing a prototype application that will assemble and mount a hot-swapped drive array, mount it, transfer files to it, unmount it, and stop the array. And it is an application delivered by a local webserver (don't ask). I don't want to do any of the incredibly stupid acts of making madadm and mount/umount setuid root, nor do I want to run the webserver as root. Instead, I took the slightly less stupid approach of invoking madadm and mount/umount with a hardcoded C application that is setuid root. (We can debate the stupidity of this -- I know it isn't best, but it is fast and less stupid than the alternatives presented above). This isn't really an answer to your question, but isn't this an ideal application for sudo? Make a shell script with the mdadm command(s) you want. And set it up so apache or whatever your web server runs as able to run your shell script as root without authentication. Ian -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Proposed enhancement to mdadm: Allow --write-behind= to be done in grow mode.
There doesn't seem to be any designated place to send bug reports and feature requests to mdadm, so I hope I am doing the right thing by sending it here. I have a small patch to mdamd which allows the write-behind amount to be set a array grow time (instead of currently only at grow or create time). I have tested this fairly extensively on some arrays built out of loop back devices, and once on a real live array. I haven't lot any data and it seems to work OK, though it is possible I am missing something. --- mdadm-2.6.1/mdadm.c.writebehind 2006-12-21 16:12:50.0 +1030 +++ mdadm-2.6.1/mdadm.c 2007-06-30 13:16:22.0 +0930 @@ -827,6 +827,7 @@ bitmap_chunk = bitmap_chunk ? bitmap_chunk * 1024 : 512; continue; + case O(GROW, WriteBehind): case O(BUILD, WriteBehind): case O(CREATE, WriteBehind): /* write-behind mode */ write_behind = DEFAULT_MAX_WRITE_BEHIND; -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed enhancement to mdadm: Allow --write-behind= to be done in grow mode.
On Tue, 2007-07-03 at 15:03 +0100, David Greaves wrote: Ian Dall wrote: There doesn't seem to be any designated place to send bug reports and feature requests to mdadm, so I hope I am doing the right thing by sending it here. I have a small patch to mdamd which allows the write-behind amount to be set a array grow time (instead of currently only at grow or create time). I have tested this fairly extensively on some arrays built out of loop back devices, and once on a real live array. I haven't lot any data and it seems to work OK, though it is possible I am missing something. Sounds like a useful feature... Did you test the bitmap cases you mentioned? Yes. And I can use mdadm -X to see that the write behind parameter is set in the superblock. I don't know any way to monitor how much the write behind feature is being used though. My motivation was for doing this was to enable me to experiment to see how effective it is. Currently I have a Raid 0 array across 3 very fast (15k rpm) scsi disks. This array is mirrored by a single large vanilla ata (7.2k rpm) disk. I figure that the read performance of the combination is basically the read performance of the Raid 0, and the sustained write performance is basically that of the ata disk, which is about 6:1 read to write speed. I also see typically about 6 times the read traffic to write traffic. So I figure it should be close to optimal IF the bursts of write activity are not too long. Does anyone know how I can monitor the number of pending writes? Where are these queued? Are they simply stuck on the block device queue (and I could see with iostat) or does the md device maintain its own special queue for this? Ian -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does --write-behind= have to be done at create time?
On Thu, 2007-06-28 at 23:22 +0930, Ian Dall wrote: I was wanting to try out the --write-behind option. I have a raid1 with bitmaps and write-mostly enabled, which are all the pre-requisites, I think. It would be nice if you could tweak this parameter on a live array, but failing that, it is hard to see why it couldn't be done at assemble time. mdadm wont let me though. Is this a fundamental limitation? Looking through the mdadm source code it seems like case O(BUILD, WriteBehind): case O(CREATE, WriteBehind): /* write-behind mode */ could be changed to case O(GROW, WriteBehind): case O(BUILD, WriteBehind): case O(CREATE, WriteBehind): /* write-behind mode */ and everything would be OK. I am completely new to this code though, so I am I missing something? If you already had a bitmap you would need to remove it first (--bitmap=none) and then grow it back with writebehind set. Ian -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid=noautodetect is apparently ignored?
On Wed, 2007-06-27 at 08:48 -0700, Andrew Burgess wrote: Odd Maybe you have an initrd which is loading md as a module, then running raidautorun or similar? .. I suspect that the last comment is the clue, after pivotroot I bet it runs another init, not from the boot/initrd images, but from the init.d in the root filesystem. You are absolutely correct. On Fedora core5, in rc.sysinit echo raidautorun /dev/md0 | nash --quiet if [ -f /etc/mdadm.conf ]; then /sbin/mdadm -A -s fi But my original observation was correct. The noautodetect was/is being ignored because (whenever) there is an initrd. FC5 doesn't support raid root partitions (mkinitrd doesn't put the right stuff in initrd), but FC7 tries to. I have upgraded and things are mostly correct. Albeit, FC7 doesn't support my nested raid configuration and so it took some coaxing to get the the upgrade done and a hack to coax mkinitrd into doing the right thing. Putting mdadm.conf on a floppy disk plus a little intervention with a virtual console early in the upgrade process worked wonders. One quick way to test this is to boot with init=/bin/sh This lets all the initrd stuff run but nothing from the root filesystem. Neat idea. I'll try and remember that for the future. -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Does --write-behind= have to be done at create time?
I was wanting to try out the --write-behind option. I have a raid1 with bitmaps and write-mostly enabled, which are all the pre-requisites, I think. It would be nice if you could tweak this parameter on a live array, but failing that, it is hard to see why it couldn't be done at assemble time. mdadm wont let me though. Is this a fundamental limitation? A related question, if I do recreate the same array, with exactly the same parameters (except for the write-behind value) will my data still be OK? -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
raid=noautodetect is apparently ignored?
When I try and disable auto detection, with kernel boot parameters, it goes ahead and auto assembles and runs anyway. The md= parameters seem to be noticed, but don't seem to have any other effect (beyond resulting in a dmesg). Here is the result $ dmesg | egrep 'raid|md:' Kernel command line: ro root=/dev/sda8 raid=noautodetect md=1,/dev/sdb2,/dev/sdc2,/dev/sdd2 md=2,/dev/sdb3,/dev/sdc3,/dev/sdd3 md=3,/dev/md1,/dev/hda2 md=4,/dev/md2,/dev/hda3 single md: Will configure md1 (super-block) from /dev/sdb2,/dev/sdc2,/dev/sdd2, below. md: Will configure md2 (super-block) from /dev/sdb3,/dev/sdc3,/dev/sdd3, below. md: Will configure md3 (super-block) from /dev/md1,/dev/hda2, below. md: Will configure md4 (super-block) from /dev/md2,/dev/hda3, below. md: Autodetecting RAID arrays. md: autorun ... md: considering sdd4 ... md: adding sdd4 ... md: sdd2 has different UUID to sdd4 md: sdd1 has different UUID to sdd4 md: adding sdc4 ... md: sdc2 has different UUID to sdd4 md: sdc1 has different UUID to sdd4 md: adding sdb4 ... md: sdb2 has different UUID to sdd4 md: sdb1 has different UUID to sdd4 md: hda3 has different UUID to sdd4 md: hda2 has different UUID to sdd4 md: created md2 md: bindsdb4 md: bindsdc4 md: bindsdd4 md: running: sdd4sdc4sdb4 md: raid0 personality registered for level 0 raid0: looking at sdd4 raid0: comparing sdd4(8409856) with sdd4(8409856) raid0: END raid0: == UNIQUE raid0: 1 zones raid0: looking at sdc4 raid0: comparing sdc4(8409856) with sdd4(8409856) raid0: EQUAL raid0: looking at sdb4 raid0: comparing sdb4(8409856) with sdd4(8409856) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 25229568 blocks. raid0 : conf-hash_spacing is 25229568 blocks. raid0 : nb_zone is 1. raid0 : Allocating 4 bytes for hash. md: considering sdd2 ... md: adding sdd2 ... md: sdd1 has different UUID to sdd2 md: adding sdc2 ... md: sdc1 has different UUID to sdd2 md: adding sdb2 ... md: sdb1 has different UUID to sdd2 md: hda3 has different UUID to sdd2 md: hda2 has different UUID to sdd2 md: created md1 md: bindsdb2 md: bindsdc2 md: bindsdd2 md: running: sdd2sdc2sdb2 raid0: looking at sdd2 raid0: comparing sdd2(8409856) with sdd2(8409856) raid0: END raid0: == UNIQUE raid0: 1 zones raid0: looking at sdc2 raid0: comparing sdc2(8409856) with sdd2(8409856) raid0: EQUAL raid0: looking at sdb2 raid0: comparing sdb2(8409856) with sdd2(8409856) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 25229568 blocks. raid0 : conf-hash_spacing is 25229568 blocks. raid0 : nb_zone is 1. raid0 : Allocating 4 bytes for hash. md: considering sdd1 ... md: adding sdd1 ... md: adding sdc1 ... md: adding sdb1 ... md: hda3 has different UUID to sdd1 md: hda2 has different UUID to sdd1 md: created md0 md: bindsdb1 md: bindsdc1 md: bindsdd1 md: running: sdd1sdc1sdb1 md: raid1 personality registered for level 1 raid1: raid set md0 active with 3 out of 3 mirrors md: considering hda3 ... md: adding hda3 ... md: hda2 has different UUID to hda3 md: created md4 md: bindhda3 md: running: hda3 raid1: raid set md4 active with 1 out of 2 mirrors md: considering hda2 ... md: adding hda2 ... md: created md3 md: bindhda2 md: running: hda2 raid1: raid set md3 active with 1 out of 2 mirrors md: ... autorun DONE. By way of context, this is kernel 2.6.20. I have set two striped (raid0) arrays, md1 and md2. Each of these is mirrored by with a single partition (hda2 and hda3) to form two raid 1 devices md3 and md4. This works perfectly if I start and stop the md3 and md4 arrays from mdadm. However the boot time autodetection always assembles degraded arrays (see the 1 out of 2 messages above). I presume this is because it only considers real physical partitions of type Linux raid autodetect and is not considering md1 and md2 as candidate devices to form further arrays. This is why I am trying to disable the autodetection, to see if directly specifying the raid configuration would help. This is driving me nuts. Maybe changing the type of the hda partitions would help? Any clues appreciated. Ian -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux
Re: raid=noautodetect is apparently ignored?
On Tue, 2007-06-26 at 16:38 +1000, Neil Brown wrote: On Tuesday June 26, [EMAIL PROTECTED] wrote: When I try and disable auto detection, with kernel boot parameters, it goes ahead and auto assembles and runs anyway. The md= parameters seem to be noticed, but don't seem to have any other effect (beyond resulting in a dmesg). Odd Maybe you have an initrd which is loading md as a module, then running raidautorun or similar? I don't think so. lsmod doesn't show a md module (even though md is clearly available). Also if I break open the current initrd, init (the script) looks like this: #!/bin/nash mount -t proc /proc /proc setquiet echo Mounting proc filesystem echo Mounting sysfs filesystem mount -t sysfs /sys /sys echo Creating /dev mount -o mode=0755 -t tmpfs /dev /dev mkdir /dev/pts mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts mkdir /dev/shm mkdir /dev/mapper echo Creating initial device nodes mknod /dev/null c 1 3 mknod /dev/zero c 1 5 mknod /dev/systty c 4 0 mknod /dev/tty c 5 0 mknod /dev/console c 5 1 mknod /dev/ptmx c 5 2 mknod /dev/rtc c 10 135 mknod /dev/tty0 c 4 0 mknod /dev/tty1 c 4 1 mknod /dev/tty2 c 4 2 mknod /dev/tty3 c 4 3 mknod /dev/tty4 c 4 4 mknod /dev/tty5 c 4 5 mknod /dev/tty6 c 4 6 mknod /dev/tty7 c 4 7 mknod /dev/tty8 c 4 8 mknod /dev/tty9 c 4 9 mknod /dev/tty10 c 4 10 mknod /dev/tty11 c 4 11 mknod /dev/tty12 c 4 12 mknod /dev/ttyS0 c 4 64 mknod /dev/ttyS1 c 4 65 mknod /dev/ttyS2 c 4 66 mknod /dev/ttyS3 c 4 67 echo Setting up hotplug. hotplug echo Creating block device nodes. mkblkdevs echo Loading scsi_mod.ko module insmod /lib/scsi_mod.ko echo Loading sd_mod.ko module insmod /lib/sd_mod.ko echo Loading qla1280.ko module insmod /lib/qla1280.ko echo Loading jbd.ko module insmod /lib/jbd.ko echo Loading ext3.ko module insmod /lib/ext3.ko echo Loading dm-mod.ko module insmod /lib/dm-mod.ko echo Loading dm-mirror.ko module insmod /lib/dm-mirror.ko echo Loading dm-zero.ko module insmod /lib/dm-zero.ko echo Loading dm-snapshot.ko module insmod /lib/dm-snapshot.ko mkblkdevs resume /dev/sda7 echo Creating root device. mkrootdev -t ext3 -o defaults,ro /dev/sda8 echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot -- Ian Dall [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
