patches for mdadm 1.8.0 (auto=dev and stacking of devices)
hello, i attach two patches for mdadm 1.8.0 the first one adds an auto=dev parameter rationale: udev does not create /dev/md* device files, so we need a way to create them when assembling the md device. auto=yes allocates the first free minor number, so mdadm -A --auto=yes /dev/md2 yelds a weird result if /dev/md2 is the first device created (it would use 0 as minor) here comes auto=dev which would use the standard minor number for /dev/md2. the second one fixes creation of stacked devices. it adds a missing close(mdfd) in mdadm.c that caused the BLKGETSIZE64 ioctl in load_super to fail if the device was created in the same mdadm run. (* This is very important to fix *) It also modifies load_conffile in config.c to recreate the device list at each run if partition is given as config file or appears in a DEVICE line. This allows DEVICE partition to consider md devices created during the same run of mdadm, removing the need to add /dev/md?? to the DEVICE line to enable stacked devices. Regards, L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ mdadm-1.8.0-autodev.patch.bz2 Description: Binary data mdadm-1.8.0-stacked.patch.bz2 Description: Binary data
Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)
Lars Marowsky-Bree [EMAIL PROTECTED] wrote: On 2005-01-23T16:13:05, Luca Berra [EMAIL PROTECTED] wrote: the first one adds an auto=dev parameter rationale: udev does not create /dev/md* device files, so we need a way to create them when assembling the md device. Am I missing something but shouldn't this be fixed by having udev + hotplug create the /dev entry correctly? :-) I mussht find out shabout udev b'fre it goesh away. I didn't realize that hotplug could get involved. Will block.agent do that kind of trick if I ask it to? Must experiment. Nice idea. Peer - 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: patches for mdadm 1.8.0 (auto=dev and stacking of devices)
Lars Marowsky-Bree wrote: On 2005-01-23T16:13:05, Luca Berra [EMAIL PROTECTED] wrote: the first one adds an auto=dev parameter rationale: udev does not create /dev/md* device files, so we need a way to create them when assembling the md device. Am I missing something but shouldn't this be fixed by having udev + hotplug create the /dev entry correctly? There's a chicken-n-eggs problem here. In order for mdadm to create an md device (so it will be noticed by udev/hotplug), it have to open the control device, which, in case of md, is just any /dev/mdN. But before first array gets assembled, there's NO mdN entries in /dev. mdadm tries to open /dev/md1 to get control interface, which isn't created automatically. When an array actually gets created, it will be noticied by hotplug/udev as it should be (provided everything is set up correctly ofcourse). BTW, is there a real need to do that? In theory, one might just create the necessary /dev/md1 from within startup script... /mjt - 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: patches for mdadm 1.8.0 (auto=dev and stacking of devices)
On Sun, Jan 23, 2005 at 07:46:29PM +0300, Michael Tokarev wrote: Lars Marowsky-Bree wrote: On 2005-01-23T16:13:05, Luca Berra [EMAIL PROTECTED] wrote: the first one adds an auto=dev parameter rationale: udev does not create /dev/md* device files, so we need a way to create them when assembling the md device. Am I missing something but shouldn't this be fixed by having udev + hotplug create the /dev entry correctly? There's a chicken-n-eggs problem here. In order for mdadm to create an md device (so it will be noticed by udev/hotplug), it have to open the control device, which, in case of md, is just any /dev/mdN. But before first array gets assembled, there's NO mdN entries in /dev. exactly mdadm tries to open /dev/md1 to get control interface, which isn't created automatically. When an array actually gets created, it will be noticied by hotplug/udev as it should be (provided everything is set up correctly ofcourse). I believe the correct solution to this would be implementing a char-misc /dev/mdadm device that mdadm would use instead of the block device, like device-mapper does. Alas i have no time for this in the forseable future. BTW, is there a real need to do that? In theory, one might just create the necessary /dev/md1 from within startup script... I would have done it in a script if --auto was not implemented, the changes to have auto=dev are not big, mostly man page and indenting. Regards, L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - 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: patches for mdadm 1.8.0 (auto=dev and stacking of devices)
Luca Berra [EMAIL PROTECTED] wrote: I believe the correct solution to this would be implementing a char-misc /dev/mdadm device that mdadm would use instead of the block device, like device-mapper does. Alas i have no time for this in the forseable future. It's a generic problem (or non-problem) - there's nothing wrong with mdadm needing a special device file nor with the driver allowing ioctls on any of the minors. Device files have traditionally always been supplied with the o/s, so it is the duty of an install script to make them if they will or might be needed later. And in the absence of an install script, a boot script. Making special device files on demand requires the cooperation of the driver and devfs (and since udev apparently replaces devfs, udev). One would need to add the code to the driver. BTW, is there a real need to do that? In theory, one might just create the necessary /dev/md1 from within startup script... I would have done it in a script if --auto was not implemented, the changes to have auto=dev are not big, mostly man page and indenting. I'm not sure I follow that. If I understand you, --auto was what you added to mdadm to make the special device files. Personally I would prefer there to be no unannounced making of device files, but yours is an extra flag so it does no harm in that sense. However, I think it is a mistaken addition. You can see that by asking yourself why EVERY control utility does not have that option in it. Hdparm? Fdisk? The answer is: because it's (a) silly, (b) none of its business. And the same applies here. If the sysadmin does not want a dev file, then let him be. If he wants one, let him make it. However, as a matter of convenience, I would prefer that the driver made the devices in /dev or /sys or wherever if it can. I don't recall if the code is there or not! Is there a udev document anywhere? I searched in 2.6.8.1 and found nothing (I won't burden you with the details of my obviously too cursory search). Peter - 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
