Re: RAID1 - Need help doing it the hard way
E.g. you setup /dev/hda5, /dev/hda6, and /dev/hda7 on the extended partition, then if you delete /dev/hda6, the remaining partitions will be labelled /dev/hda5 and /dev/hda6. ... The way to fix the device renaming problem is to use devfs. I haven't tried it, so I don't know how well it works, but it sounds like it should make the care of feeding of /dev much nicer. works wonderfully with disks and controllers, does not work with extended partitions, sorry. This is an historical bad design of PC. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
Re: RAID1 - Need help doing it the hard way
On Mon, Sep 11, 2000 at 09:50:27AM +0200, Danilo Godec wrote: On Mon, 11 Sep 2000, Luca Berra wrote: The way to fix the device renaming problem is to use devfs. I haven't tried it, so I don't know how well it works, but it sounds like it should make the care of feeding of /dev much nicer. works wonderfully with disks and controllers, does not work with extended partitions, sorry. This is an historical bad design of PC. In such case, you can create a minimum size /dev/hda6 partition, just to keep /dev/hda7 in place. anyway if you use the raid autorun feature to start your raid devices it will find the correct partitions looking at the raid superblock. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
Re: WebMin LVM module development
On Wed, Dec 06, 2000 at 05:43:55PM +0800, Michael Boman wrote: - I have problem using MD as a PV of my VG, any hints what it can be? output mike:/mnt# vgextend vg_test /dev/md0 vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte vgextend -- ERROR: no physical volumes usable to extend volume group "vg_test" /output It's a known problem, LVM 0.8final does not work LVM 0.8.1 does work LVM 0.9 does not again Tomorrow is holiday in Milan, so i will try to give it a look Regards, L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
Re: bootable raid 1
On Mon, Dec 18, 2000 at 09:15:51AM -0500, Charles Wilkins wrote: I am currently doing bootable raid 1 with all of the latest patches for 2.2.18 and then some. When I try to boot the system with either drive removed, I get a bunch of 010101010's in an endless loop. Yet, when both drives are in, the system comes up fine. What am I doing wrong? Using lilo 21.5 With Lilo 21.5 you don't need any geometry junk, nor to use more than one lilo.conf just use md0 as if you had only a normal disk. remember to include a 'default' entry. L. lilo.conf.hda disk=/dev/md0 bios=0x80 sectors=63 heads=15 cylinders=13328 -- 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]
Re: [linux-lvm] Installation question: SW RAID1 + LVM for boot and root
On Thu, Feb 08, 2001 at 09:39:49PM +0100, Luka Renko wrote: 1. Is it possible to install OS directly on SW RAID1 + LVM? If not, how to do it in multiple steps (RAID HOWTO just mentions how to install OS on SW RAID1, but not using LVM on top of SW RAID)? not yet, i used an extra disk to install the system on, then cpio-ed everything. 2. Are there any known problems on LVM over SW RAID1 (I have seen some bug reports on that)? no, if you use the 0.9.1betaX 3. RAID HOWTO talks about slow read performance with RAID1 and that it should be improved in new patches to come? Is this still true? Do I need to apply any patches for that? i believe the code in 2.4 is optimized (but you better look for mikka's patch and see if it applies to you, i use raid5 so i dinna check). 4. I have also seen some discussion about issues with putting swap on SW RAID? Is this still true? with 2.2 it is problematic and cannot be fixed, it has been fixed in 2.4 5. Should I create one or two (system, user) md devices? Is there any difference? What about multiple LVM VGs and PVs? It seems to me, that it does not make any real difference... 1 md device, 1 pv, 1 vg (no way out with only 2 disks) i dunno if the latest lilo can see LVM-OVER-RAID1, if not 1 small md device for /boot 1 big md for lvm 6. What version of kernel (2.2 or 2.4) is better for such configuration? What version of SW RAID and LVM should I use? Are there any additional patches I should apply? 2.4 (sw raid is included, lvm patches from cvs) -- 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]
Re: partitions for RAID volumes?
[I'll Cc the lvm-devel list on this]
Neil,
what you are stating here is a bit distressing,
since i am using LVM over raid5.
I'd like to help in solving this kind of problems...
On Mon, Feb 26, 2001 at 01:04:23PM +1100, Neil Brown wrote:
On Thursday February 22, [EMAIL PROTECTED] wrote:
[Sorry about the delay in replying, but as this mail was not addressed
to me ("neilb" did not appear in headers) it didn't get a very high
priority in my mail reading. Please, when sending email to me,
address it to me so my filtering can work. Thanks]
hello,
looking at your patches i was trying to understand patch-J-r5align
does it mean that that particular request is not handled by the
stripe cache?
Yes. A request that is not properly aligned cannot be handled by the
stripe cache. I'm not certain exactly what will happen, but I suspect
that it would mostly work but would occasionally cause data corruption
if a differently aligned request for a nearby stripe were written at
the same time. Occasional corruption is not something that I want!
besides printing the warning (wouldn't it be better to print it only once
or once in a while, instead of at every request)
Arguable it would be better to rate-limit the printing of the message,
but really, I don't want anyone to use raid5 in a situaiton where
requests might not be aligned, and I want them to get a very clear
message this it doesn't work.
anyway once you properly configure your LVM system, misaligned requests happen only
during vg operations, which are rare.
i actually goofed on this, i was thinking something else...
what lvm does during vg operations is reading data in non 4k sized blocks
(same happens when using dd on the md device)
Feb 24 21:56:30 Moskowskaya kernel: raid5: switching cache buffer size, 4096 -- 1024
Feb 24 21:56:30 Moskowskaya kernel: raid5: switching cache buffer size, 1024 -- 4096
Feb 24 21:56:30 Moskowskaya kernel: raid5: switching cache buffer size, 0 -- 4096
But even once is too often if it could corrupt your data.
I don't know much about the details of LVM, but if you can create
partitions that are not on a 4K boundry in the real device, then you
could certainly create a situation with lots of misaligned requests.
i don't think this is the case since LVM divides the physical disk
in chunks called PE sized "from 8KB to 512MB in powers of 2 and unit KB"
I hope to remove this restriction eventually, but until then, I want
people to be able to know when potentially bad things are happening.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
--
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]
Re: Need Patch for 2.2.19
hello, some browsers are known to mess with that particular patch try redownloading it with a different program On Mon, Apr 02, 2001 at 12:15:12PM +0200, Jos Luis Arenas de la Fuente wrote: I don't find the patch for kernel 2.2.19. In people.redhat.com/mingo the latest is for 2.2.17 and the patch raid-2.2.19-A0 of http://www.kernel.org/pub/linux/kernel/people/mingo/raid-patches/ causes a lot of hunk's. I need to update due recent security bug in kernels 2.2.19 Sorry for my bad english. JLA - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] -- 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]
Re: Hardware RAID Advice Sought
On Thu, Apr 26, 2001 at 06:26:44PM +0200, Holger Kiehl wrote: On Thu, 26 Apr 2001, root wrote: OK, a stupid follow-up question: if I start with 3 drives in a RAID5, I will have 2 data drives and 1 parity drive, correct? Now, if I add 3 more drives as a second logical volume, will I have to devote 1 of them to parity again, or can the initial parity drive be used for both? I would like reserve as many of the drives for data as possible, even if it means spending more money in the near term to get all 6 drives. In raid 4 you have a parity disk, in raid 5 the parity is stripped across all disks. true. anyway for disk waste it is the same you always have N-1 in a raid5 if you add a second logical volume (=raid array) it is a different array so it needs a different parity. you can anyway extend the current raid5 (at least with AMI -i tried hp netraids 1 3). Thanks for all the help. Basic real-world questions like this don't tend to make it into faqs, but can go a long way to helping you make informed buying decisions. Why not try software raid? Its faster and cheaper. yup, but with hw raid you save cpu cycles and, more important you have a battery backup. 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]
Re: Software RAID clustering support
On Thu, Apr 26, 2001 at 06:18:33PM +0200, Holger Kiehl wrote: On Fri, 27 Apr 2001, Michael Clark wrote: Has anybody looked at clustering support for Software RAID (ie. in a shared disk environment: shared scsi or FC). I guess this may have come up on the list before but I didn't find anything in the maillist archives (LVM guys once discussed this but not sure if there is any existing support for this) Have a look at http://www.complang.tuwien.ac.at/reisner/drbd/ nope drbd handles data replication, what Michael is looking for is a distributed lock system. LVM guys are thinking of something for future releases, but at the moment i don't know of anything existing. maybe some creative use of heartbeat? 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]
Re: Swap to RAID-1 mirror?
someone asked me privately about creating a file on a md and swapping on it, but i flost the mail, anyway, swapping on a file works the same way as swapping on a partition. L. On Thu, May 10, 2001 at 08:50:42PM +0200, Luca Berra wrote: On Thu, May 10, 2001 at 11:44:45AM -0700, Kaelin Colclasure wrote: Greetings, that I could find (v. 0.90.7 19th of January 2000) had this to say about swapping to a RAID device: in short swap on raid works with 2.4 it doesn't work with 2.2 (during reconstruction) same can be said for journaling fs over raid noone here wants to remember gory details, search for the list archives. (you will alsy find solution for delayng swapping until reconstruction is done at boot) 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] -- 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]
Re: switching cache buffer size?
On Fri, May 25, 2001 at 01:52:25PM +0300, Kaj-Michael Lang wrote: I get a lot these after moving to 2.4 from 2.2(patched). What are they? raid5: switching cache buffer size, 1024 -- 4096 raid5: switching cache buffer size, 4096 -- 1024 raid5: switching cache buffer size, 1024 -- 4096 raid5: switching cache buffer size, 4096 -- 1024 raid5: switching cache buffer size, 1024 -- 4096 lvm over raid5??? if you get a lot of them, continuous stream, check that every filesystem has the same blocksize. else your raid5 will perform really poorly. it also happens during lvm operations. btw if you swap over there block-size of swap is page size 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]
Re: kernel 2.2.x and swap to a raid device/file
On Mon, Jun 04, 2001 at 07:18:57PM +0100, Corin Hartland-Swann wrote: On Mon, 4 Jun 2001, Luca Berra wrote: On Mon, Jun 04, 2001 at 05:13:11AM +0100, Corin Hartland-Swann wrote: What I really hate is the recommendations that you should always have twice as much swap as main memory. I recently tried out FreeBSD on a box with 4096M RAM. When I hit auto-allocate (or some such) it gave me 8192M swap! As soon as main programs head into swap thrashing ensues and your server goes to hell :( Some unices (i know of HP-UX) and W.NT insist on allocating enough space on swap to fully swap out any process, so you cannot allocate 1Gb ram if you don't have at least 1Gb swap (the other 1Gb is what would be really used as normal swap) [linux is not the case] Besides that other unices do use swap as a dump device, i know sgi is adding dump support to linux, but i have never seen it working. Lastly some application software do seem to allocate enormous quantities of memory (sap reccomends about 3 time the system memory for swap, no this figure is not given any amount of menory) 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]
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)
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: Software RAID 0+1 with mdadm.
On Tue, Jan 25, 2005 at 02:28:21PM -0800, Brad Dameron wrote: Everything seems ok after boot. But again no /dev/md0 in /proc/mdstat. But then if I do a mdadm --assemble --scan it will then load /dev/md0. there is a bug in mdadm, see my mail patches for mdadm 1.8.0 or wait for 1.9.0 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: Software RAID 0+1 with mdadm.
On Thu, Jan 27, 2005 at 04:24:34PM +1100, Neil Brown wrote: On Wednesday January 26, [EMAIL PROTECTED] wrote: This bug that's fixed in 1.9.0, is in a bug when you create the array? ie do we need to use 1.9.0 to create the array. I'm looking to do the same but my bootdisk currently only has 1.7.soemthing on it. Do I need to make a custom bootcd with 1.9.0 on it? This issue that will be fixed in 1.9.0 has nothing to do with creating the array. It is only relevant for stacked arrays (e.g. a raid0 made out of 2 or more raid1 arrays), and only if you are using mdadm --assemble --scan (or similar) to assemble your arrays, and you specify the devices to scan in mdadm.conf as DEVICES partitions (i.e. don't list actual devices, just say to get them from the list of known partitions). actually the last statement is not true, a missing close(mdfd); causes mdadm --assemble --scan to fail the first round even if you do specify DEV /dev/mdX in mdadm.conf. 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: Broken harddisk
On Tue, Feb 01, 2005 at 03:02:54PM +, Robin Bowes wrote: Mike Hardy wrote: If you're drives don't talk SMART (older ones don't, it doesn't work through all interfaces either) then by all means take Guy's advice. A 'dd' test is certainly valuable. But if they do talk SMART, I think its better True enough. However, until SMART support makes it into linux SATA drivers I'm pretty much stuck with dd! http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/ -- 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: Problem with auto-assembly on Itanium
On Wed, Mar 09, 2005 at 11:28:48AM +0100, Jimmy Hedman wrote: Is there any way i can make this work? Could it be doable with mdadm in a initrd? mdassembled was devise for this purpose. create an /etc/mdadm.conf with echo DEVICE partitions /etc/mdadm.conf /sbin/mdadm -D -b /dev/md0 | grep '^ARRAY' /etc/mdadm.conf copy the mdadm.conf and mdassemble to initrd make linuxrc run mdassemble. 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: Problem with auto-assembly on Itanium
On Thu, Mar 10, 2005 at 11:03:44AM +0100, Jimmy Hedman wrote: On Wed, 2005-03-09 at 17:43 +0100, Luca Berra wrote: On Wed, Mar 09, 2005 at 11:28:48AM +0100, Jimmy Hedman wrote: Is there any way i can make this work? Could it be doable with mdadm in a initrd? mdassembled was devise for this purpose. create an /etc/mdadm.conf with echo DEVICE partitions /etc/mdadm.conf /sbin/mdadm -D -b /dev/md0 | grep '^ARRAY' /etc/mdadm.conf copy the mdadm.conf and mdassemble to initrd make linuxrc run mdassemble. So there are no way of doing it the same way i386 does it, ie scanning the partitions and assembly the raid by it self? Is this a bug on the itanium (GPT partition scheme) or is this intentional? if you mean the in-kernel autodetect junk, you should only be happy it does not work on your system, so you are not tempted to use it. even on i386 it is badly broken, and i won't return on the subject. it has been discussed on this list to boredom. L. btw. you don't need cc-ing me. i read the list. 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: [PATCH 1/2] md bitmap bug fixes
On Fri, Mar 18, 2005 at 02:42:55PM +0100, Lars Marowsky-Bree wrote: The problem is for multi-nodes, both sides have their own bitmap. When a split scenario occurs, and both sides begin modifying the data, that bitmap needs to be merged before resync, or else we risk 'forgetting' that one side dirtied a block. on a side note i am wondering what would the difference be on using this approach within the md driver versus DRBD? 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: [PATCH 1/2] md bitmap bug fixes
On Mon, Mar 21, 2005 at 11:07:06AM -0500, Paul Clements wrote: All I'm saying is that in a split-brain scenario, typical cluster frameworks will make two (or more) systems active at the same time. This I sincerely hope not. -- 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: md autodetection
On Mon, Mar 21, 2005 at 09:06:44AM +0100, Nils-Henner Krueger wrote: I've got a few questions about raid autodetection at boot time. i usually have a single answer, don't use it. but i see you are struck with rh, so... To use a mirrored boot device, I have to use raid autodetection to have the md devices running early enough? yes To have autodection recognise a disk device, it has to run after the appropriate device driver, right? yes In my current setup, running RHEL3 with kernel 2.4.21, I have the system installed on a scsi disk. The scsi driver ist loaded was that an _is_ or an _isn't_ ??? as module and added to the initrd. Currently raid autodection takes place long before the scsi device driver is loaded: redhats' mkinitrd reruns autodetection after module loading. Is there a way to run raid autodection (again?) later in the boot sequence to detect not only IDE devices but other things like scsi, too? you better use mdadm instead. i even wrote a tool, mdassemble which is shipped with mdadm and is suited for replacing autodetection in initrds. Last question: :-) Is it possible to make a distinction between some md-devices which should be detected and started by raid autodetection and others which should be left untouched? autodetection only considers type fd partition, mdadm and raidstart don't actually care. -- 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: [PATCH 1/2] md bitmap bug fixes
On Mon, Mar 21, 2005 at 02:58:56PM -0500, Paul Clements wrote: Luca Berra wrote: On Mon, Mar 21, 2005 at 11:07:06AM -0500, Paul Clements wrote: All I'm saying is that in a split-brain scenario, typical cluster frameworks will make two (or more) systems active at the same time. This I sincerely hope not. Perhaps my choice of wording was not the best? I probably should have said, there is no foolproof way to guarantee that two systems are not active. Software fails, human beings make mistakes, and surely even STONITH devices can be misconfigured or can fail (or cannot be used for one reason or another). well, careful use of an arbitrator node, possibly in a different location, helps avoiding split-brains, and stonith is a requirement At any rate, this is all irrelevant given the second part of that email reply that I gave. You still have to do the bitmap combining, regardless of whether two systems were active at the same time or not. I still maintain that doing data-replication with md over nbd is a painful and not very useful exercise. If we want to do data-replication, access to the data-replicated device should be controlled by the data replication process (*), md does not guarantee this. (*) i.e. my requirements could be that having a replicated transaction is more important that completing the transaction itself, so i might want to return a disk error in case replica fails. or to the contrary i might want data availability above all else, maybe data does not change much. or something in between, data availability above replication, but data validity over availability. this is probably the most common scenario, and the more difficult to implement correctly. In any case it must be possible to control exactly which steps should be automatically done in case of failure. and in case of rollback, with the sane default would be die rather than modify any data, in case of doubt. 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: [PATCH 1/2] md bitmap bug fixes
On Tue, Mar 22, 2005 at 11:02:16AM +0100, Peter T. Breuer wrote: Luca Berra [EMAIL PROTECTED] wrote: If we want to do data-replication, access to the data-replicated device should be controlled by the data replication process (*), md does not guarantee this. Well, if one writes to the md device, then md does guarantee this - but I find it hard to parse the statement. Can you elaborate a little in order to reduce my possible confusion? I'll try in fault tolerant architechture where we have two systems each with a local storage which is exposed to the other system via nbd or similar. One node is active and writes data to an md device composed from the local storage and the nbd device. The other node is stand-by and ready to take the place of the former in case it fails. I assume the data replication is synchronous at the moment (the write system call returns when io has been submitted to both the underlying devices) (*) we can have a series of failures which must be accounted for and dealt with according to a policy that might be site specific. A) Failure of the standby node A.1) the active is allowed to continue in the absence of a data replica A.2) disk writes from the active should return an error. we can configure this setting in advance. B) Failure of the active node B.1) the standby node takes immediately ownership of data and resumes processing B.2) the standby node remains idle C) communication failure between the two nodes (and we don't have an external mechanism to arbitrate the split brain condition) C.1) both system panic and halt C.2) A1 + B2 C.3) A2 + B2 C.4) A1 + B1 C.5) A2 + B1 (which hopefully will go to A2 itself) D) communication failure between the two nodes (admitting we have an external mechanism to arbitrate the split brain condition) D.1) A1 + B2 D.2) A2 + B2 D.2) B1 then A1 D.3) B1 then A2 E) rolling failure (C, then B) F) rolling failure (D, then B) G) a failed nodes is restored H) a node (re)starts while the other is failed I) a node (re)starts during C J) a node (re)starts during D K) a node (re)starts during E L) a node (re)starts during F scenarios without a sub-scenarios are left as an exercise to the reader, or i might find myself losing a job :) now evaluate all scenarios under the following drivers: 1) data availability above all others 2) replica of data above all others 3) data availability above replica, but data consistency above availability (*) if you got this far, add asynchronous replicas to the picture. Regards, Luca -- 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: RAID1 and data safety?
On Tue, Mar 29, 2005 at 01:29:22PM +0200, Peter T. Breuer wrote: Neil Brown [EMAIL PROTECTED] wrote: Due to the system crash the data on hdb is completely ignored. Data Neil - can you explain the algorithm that stamps the superblocks with an event count, once and for all? (until further amendment :-). IIRC it is updated at every event (start, stop, add, remove, fail etc...) It goes without saying that sb's are not stamped at every write, and the event count is not incremented at every write, so when and when? the event count is not incremented at every write, but the dirty flag is, and it is cleared lazily after some idle time. in older code it was set at array start and cleared only at stop. so in case of a disk failure the other disks get updated about the failure. in case of a restart (crash) the array will be dirty and a coin tossed to chose which mirror to use as an authoritative source (the coin is biased, but it doesn't matter). At this point any possible parallel reality is squashed out of existance. 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: interesting failure scenario
On Mon, Apr 04, 2005 at 01:59:09AM +0400, Michael Tokarev wrote: I just come across an interesting situation, here's the scenario. C'mon, there's plenty of ways for you to shoot yourself in the feet. :) 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: Can uuid of raid array be changed?
On Sun, Apr 17, 2005 at 05:04:13PM -0500, John McMonagle wrote: Need to duplicate some computers that are using raid 1. I was thinking of just adding adding an extra drive and then moving it to the new system. The only problem is the clones will all have the same uuids. If at some later date the drives got mixed up I could see a possibilities for disaster. Not exactly likely as the computers will be in different cities. Is there a way to change the uuid if a raid array? Is it really worth worrying about? you can recreate the array, this will not damage existing data. 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: Can uuid of raid array be changed?
On Mon, Apr 18, 2005 at 08:05:22PM -0500, John McMonagle wrote: Luca Berra wrote: On Sun, Apr 17, 2005 at 05:04:13PM -0500, John McMonagle wrote: Need to duplicate some computers that are using raid 1. I was thinking of just adding adding an extra drive and then moving it to the new system. The only problem is the clones will all have the same uuids. If at some later date the drives got mixed up I could see a possibilities for disaster. Not exactly likely as the computers will be in different cities. Is there a way to change the uuid if a raid array? Is it really worth worrying about? you can recreate the array, this will not damage existing data. L. Thanks I'll try it. I suspect I'll find out real quick but do you need to a --zero-superblock on all devices making the raid arrays? NO Will this damage the lvm2 superblock info? Probably a good idea to do a vgcfgback just to be safe.. NO the idea is after you cloned the drive, create a new array with the force flag and using as components the cloned disk and the magic word missing, this will create a new degraded array and won't touch any data. you can then hotadd a new drive to this array, it will fill the slot used by the missing keyword. 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: question regarding multipath Linux 2.6
On Thu, Sep 01, 2005 at 02:51:44PM -0400, Jim Faulkner wrote: Hello, Recently my department had a SAN installed, and I am in the process of setting up one of the first Linux machines connected to it. The machine is running Red Hat Enterprise AS4 (x86_64), which uses Linux kernel version 2.6.9-11.ELsmp. giving more info about the infamous SAN would help :) The SAN shows up twice in the kernel, as /dev/sdb and /dev/sdc. /dev/sdb is inaccessible (I get a bunch of Buffer I/O error on device sdb kernel errors), but /dev/sdc works fine. According to the administrator of the it probably is a cheapo storage with an Active/Passive storage controller, you cannot use md to handle those. He told me to use PowerPath, but I'd rather not have to reinstall or it is a long time i don't see powerpath on linux, but i am in favour of ditching proprietary multipath solutions in favour of free ones. what you want is multipath-tools http://christophe.varoqui.free.fr/ RH4 should already include a multipath-tools rpm. Regards, Luca -- 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: /proc/mdstat bug: 2.6.14.2
On Tue, Nov 29, 2005 at 11:35:18AM -0800, Andrew Burgess wrote: The time and speed display for resync is wrong, the recovery numbers are fine. The resync is actually running at a few MB/sec. md1 : active raid6 sdn1[8](S) sde1[9] sdq1[0] sdu1[6] sdo1[5] sdaa3[4] sdab1[2] sds1[1] 1757815296 blocks level 6, 128k chunk, algorithm 2 [8/6] [UUU_UUU_] [] recovery = 3.6% (10616704/292969216) finish=840.3min speed=5597K/sec md0 : active raid6 sdac2[0] sdz1[4] sdy1[2] sdx1[1] sdw1[3] sdv1[5] sdr2[6] 1875299328 blocks level 6, 128k chunk, algorithm 2 [8/7] [UUU_] [==..] resync = 33.1% (103563392/312549888) finish=1.5min speed=2288625K/sec This is a amd64 x2 but running in single processor mode because of all the timer problems with dual cpus do you have powernow modules loaded on this kernel? they might be tricking your internal clock. 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: hard drives with variable device names - mdadm raid assembly options setup
On Sat, Dec 31, 2005 at 11:44:32AM +1100, Daniel Pittman wrote: DEVICE /dev/hd* DEVICE /dev/sd* i really find DEVICE partitions to be more useful than shell patterns. 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: [klibc] Re: Exporting which partitions to md-configure
On Mon, Feb 06, 2006 at 06:47:54PM -0800, H. Peter Anvin wrote: Neil Brown wrote: Requiring that mdadm.conf describes the actual state of all volumes would be an enormous step in the wrong direction. Right now, the Linux md system can handle some very oddball hardware changes (such as on hera.kernel.org, when the disks not just completely changed names due to a controller change, but changed from hd* to sd*!) DEVICE partitions ARRAY /dev/md0 UUID=xxyy:zzyy:aabb:ccdd would catch that Dynamicity is a good thing, although it needs to be harnessed. kernel parameter md_root_uuid=xxyy:zzyy:aabb:ccdd... This could be interpreted by an initramfs script to run mdadm to find and assemble the array with that uuid. The uuid of each array is reasonably unique. I could change mdassemble to allow accepting an uuid on the command line and assemble a /dev/md0 with the specified uuid (at the moment it only accepts a configuration file, which i tought was enough for initrd/initramfs. This, in fact is *EXACTLY* what we're talking about; it does require autoassemble. Why do we care about the partition types at all? The reason is that since the md superblock is at the end, it doesn't get automatically wiped if the partition is used as a raw filesystem, and so it's important that there is a qualifier for it. I don't like using partition type as a qualifier, there is people who do not wish to partition their drives, there are systems not supporting msdos like partitions, heck even m$ is migrating away from those. In any case if that has to be done it should be done into mdadm, not in a different scrip that is going to call mdadm (behaviour should be consistent between mdadm invoked by initramfs and mdadm invoked on a running system). If the user wants to reutilize a device that was previously a member of an md array he/she should use mdadm --zero-superblock to remove the superblock. I see no point in having a system that tries to compensate for users not following correct procedures. sorry. 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: Raid 1 always degrades after a reboot.
On Mon, Feb 06, 2006 at 03:08:07PM -0800, Hans Rasmussen wrote: Hi all. After every reboot, my brand new Raid1 array comes up degraded. It's always /dev/sdb1 that is unavailable or removed. ... Mandriva 2006 download edition, upgraded from Mandrake 9.1 Kernel 2.6.12-15mdk (not rebuilt) MDADM version 00.90.01 this is the version of the md driver in the kernel, mdadm on 2006 is 1.12.0 could you please check if the array is stopped correctly at shutdown maybe temporarily removing the splash thing from lilo/grub will allow you to see more clearly. Q. does the SATA300 TX2Plus card support fakeraid? in case it does and it is enable that could conflict with md. 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: [klibc] Re: Exporting which partitions to md-configure
On Tue, Feb 07, 2006 at 07:46:59AM -0800, H. Peter Anvin wrote: Luca Berra wrote: I don't like using partition type as a qualifier, there is people who do not wish to partition their drives, there are systems not supporting msdos like partitions, heck even m$ is migrating away from those. That's why we're talking about non-msdos partitioning schemes. this still leaves whole disks If the user wants to reutilize a device that was previously a member of an md array he/she should use mdadm --zero-superblock to remove the superblock. I see no point in having a system that tries to compensate for users not following correct procedures. sorry. You don't? That surprises me... making it harder for the user to have accidental data loss sounds like a very good thing to me. making it harder for the user is a good thing, but please not at the expense of usability the only way i see a user can have data loss is if - a md array is stopped - two different filesystems are created on the component devices - these filesystems are filled with data, but not to the point of damaging the superblock - then the array is started again. if only one device is removed using mdadm the event counter would prevent the array from being assembled again. there are a lot of easier ways for shooting yourself in the feet :) if we really want to be paranoid we should modify mkXXXfs to refuse creating a filesystem if the device has an md superblock on it. (lvm2 tools are already able to ignore devices with md superblocks on them, no clue about EVMS) 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: [klibc] Re: Exporting which partitions to md-configure
On Tue, Feb 07, 2006 at 08:55:21AM -0800, H. Peter Anvin wrote: Luca Berra wrote: making it harder for the user is a good thing, but please not at the expense of usability What's the usability problem? if we fail to support all partitioning schemes and we do not support non partitioned devices. if we manage to support all this without too much code bloat i'll shut up. 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: Question: array locking, possible?
On Thu, Feb 09, 2006 at 10:28:58AM -0800, Stern, Rick (Serviceguard Linux) wrote: There is more interest, just not vocal. May want to look at LVM2 and its ability to use tagging to control enablement of VGs. This way it is not HW dependent. I believe there is space in md1 superblock for a cluster/exclusive flag, if not the name field could be used what is missing is an interface between mdadm and cmcld so mdadm can ask cmcld permission to activate an array with the cluster/exclusive flag set. 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: heavy problem with raid initialisation
On Fri, Feb 10, 2006 at 11:11:24AM +0100, Guillaume Rousse wrote: Hello. I'm using software raid with mdadm 1.7.0 on a mandrake linux 10.1, but I'm facing heavy initialisation troubles. The first array /dev/md0 is automatically created and launched at startup (though mdadm -As in init scripts), but not the second array /dev/md1. mdadm --examine --scan --config=partitions creates the second array as /dev/.tmp.md1, which I can then assemble using an explicit mdadm -A /dev/sda2 /dev/sdb2 command, but this is unpractical and failproof :/ i think this issue was squashed in a newer version of mdadm can you try rebuilding the current cooker rpm on 10.1 and try again. i don't have a 10.1 laying around to test atm. 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: Question: array locking, possible?
On Mon, Feb 13, 2006 at 06:52:47PM +0100, Chris Osicki wrote:
Luca
On Thu, 9 Feb 2006 21:48:48 +0100
Luca Berra [EMAIL PROTECTED] wrote:
On Thu, Feb 09, 2006 at 10:28:58AM -0800, Stern, Rick (Serviceguard Linux)
wrote:
There is more interest, just not vocal.
May want to look at LVM2 and its ability to use tagging to control enablement
of VGs. This way it is not HW dependent.
I believe there is space in md1 superblock for a cluster/exclusive
flag, if not the name field could be used
Great if there is space for it there is a hope.
Unfortunately I don't think my programming skills are up to
such a task as making proof-of-concept patches.
i was thinking of adding a bit in the feature_map flags to enable this
kind of behaviour, the downside of it is that kernel space code has to
be updated to account for this flags, as it is for anything in the
superblock except for name.
Neil, what would you think of reserving some more space in the superblock for
other data which can be used from user-space?
i believe playing with name is a kludge.
what is missing is an interface between mdadm and cmcld so mdadm can ask
cmcld permission to activate an array with the cluster/exclusive flag
set.
For the time being we could live without it. I'm convinced HP would
make use of it once it's there.
i was thinking something like a socket based interface between mdadm and
a generic cluster daemon, non necessarily cmcld.
And I wouldn't say mdadm should get permission from cmcld (for those
who don't know Service Guard cluster software from HP: cmcld is
the Cluster daemon). IMHO cmcld should clear the flag on the array
when initiating a fail-over in case the host which used it crashed.
no, i don't like the flag to be cleared, there is too much space for a
race. The flag should be permanent (unless it is forcibly removed with
mdadm --grow).
Once again, what I would like it for is for preventing two hosts writing
the array at the same time because I accidentally activated it.
Without cmcld's awareness of the cluster/exclusive flag I would
always run mdadm with the '--force' option to enable the array during
package startup, because if I trust the cluster software I know the
fail-over is happening because the other node crashed or it is a
manual (clean) fail-over.
if you only want this, it could be entirely implemented into mdadm, just
adding a exclusive flag to the ARRAY line in mdadm.conf
this is not foolproof, as it will only prevent mdadm -As from assembling
a device, providing the identification information on the command line
or running something like mdadm -Asc partitions, to fool it.
--
Luca Berra -- [EMAIL PROTECTED]
Communication Media Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
XAGAINST HTML MAIL
/ \
diff -urN mdadm-2.3.1/Assemble.c mdadm-2.3.1.exclusive/Assemble.c
--- mdadm-2.3.1/Assemble.c 2006-01-25 08:01:10.0 +0100
+++ mdadm-2.3.1.exclusive/Assemble.c2006-02-13 22:48:04.0 +0100
@@ -34,7 +34,7 @@
mddev_dev_t devlist,
int readonly, int runstop,
char *update,
-int verbose, int force)
+int verbose, int force, int exclusive)
{
/*
* The task of Assemble is to find a collection of
@@ -255,6 +255,15 @@
continue;
}
+ if (ident-exclusive != UnSet
+ !exclusive ) {
+ if ((inargv verbose = 0) || verbose 0)
+ fprintf(stderr, Name : %s can be activated in
exclusive mode only.\n,
+ devname);
+ continue;
+ }
+
+
/* If we are this far, then we are commited to this device.
* If the super_block doesn't exist, or doesn't match others,
* then we cannot continue
diff -urN mdadm-2.3.1/ReadMe.c mdadm-2.3.1.exclusive/ReadMe.c
--- mdadm-2.3.1/ReadMe.c2006-02-06 05:09:35.0 +0100
+++ mdadm-2.3.1.exclusive/ReadMe.c 2006-02-13 22:27:26.0 +0100
@@ -147,6 +147,7 @@
{scan, 0, 0, 's'},
{force,0, 0, 'f'},
{update, 1, 0, 'U'},
+{exclusive, 0, 0, 'x'},
/* Management */
{add, 0, 0, 'a'},
diff -urN mdadm-2.3.1/config.c mdadm-2.3.1.exclusive/config.c
--- mdadm-2.3.1/config.c2005-12-09 06:00:47.0 +0100
+++ mdadm-2.3.1.exclusive/config.c 2006-02-13 22:23:02.0 +0100
@@ -286,6 +286,7 @@
mis.st = NULL;
mis.bitmap_fd = -1;
mis.name[0] = 0;
+ mis.exclusive = 0;
for (w=dl_next(line); w!=line; w=dl_next(w)) {
if (w[0] == '/') {
@@ -386,6 +387,8 @@
fprintf(stderr, Name : auto type of
\%s\ ignored for %s\n,
w+5,
mis.devname?mis.devname:unlabeled-array);
}
+ } else if (strncasecmp(w
Re: Question: array locking, possible?
On Mon, Feb 13, 2006 at 10:53:43PM +0100, Luca Berra wrote: diff -urN mdadm-2.3.1/Assemble.c mdadm-2.3.1.exclusive/Assemble.c please note that the patch was written while i was composing the email as a proof-of-concept, it should not be considered working (or even compiling code) 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: Lilo append= , A suggestion .
On Mon, Feb 13, 2006 at 09:12:42PM -0700, Mr. James W. Laferriere wrote: Hello Neil All , I'll bet I am going to get harassed over this , but ... The present form (iirc) of the lilo append statement is append=md=d0,/dev/sda,/dev/sdb I am wondering how difficult the below would be to code ? This allows a (relatively) short strings to be append'd instead of the sometimes large listing of devices . append=md=d0,UUID=e9e0f605:9ed694c2:3e2002c9:0415c080 Ok , I got my asbestos brithes on . Have at it ;-) . Tia , JimL what about all the past threads about in-kernel autodetection? 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: 2+ raid sets, sata and a missing hd question
On Wed, Feb 15, 2006 at 01:45:21PM +1100, CaT wrote: Seeing as how SATA drives can move around if one removes one from a set (ie given sda, sdb, sdc, if sdb was removed sdc drops to sdb) would md6 come back up without problems if I were to remove either sda or sdb. if you configured mdadm correctly, you will have no problem :) hint echo DEVICE partitions /etc/mdadm.conf mdadm -Esc partitions | grep ARRAY /etc/mdadm.conf All md partitions are of type fd (Linux raid autodetect). this is surprisingly not at all relevant 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: 2+ raid sets, sata and a missing hd question
On Wed, Feb 15, 2006 at 06:44:29PM -0500, Mark Hahn wrote: hint echo DEVICE partitions /etc/mdadm.conf mdadm -Esc partitions | grep ARRAY /etc/mdadm.conf All md partitions are of type fd (Linux raid autodetect). this is surprisingly not at all relevant I'm not sure about that. I've accidentally shuffled disks before, and 0xfd resulted in all the MD's coming to life again. I never use /etc/mdadm.conf, since there doesn't seem to be much point... i did not speak about in-kernel autodetection. don't cc me on list replies unless it is really important -- 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: quota on raid
On Sat, Feb 18, 2006 at 02:12:26AM +0100, Antonello PAPA wrote: i have two disk with raid 1. i can't find documents on how to set the quotas. i whould like to set the quota on /home, can some opne help? thanks and sorry for bad english. antonello in italian: http://www.lnf.infn.it/computing/doc/AppuntiLinux/a296.html 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: quota on raid
On Sat, Feb 18, 2006 at 09:42:04AM +0100, Luca Berra wrote: On Sat, Feb 18, 2006 at 02:12:26AM +0100, Antonello PAPA wrote: i have two disk with raid 1. i can't find documents on how to set the quotas. i whould like to set the quota on /home, can some opne help? thanks and sorry for bad english. antonello in italian: http://www.lnf.infn.it/computing/doc/AppuntiLinux/a296.html sorry, this is the _current_ version http://a2.swlibero.org/a2111.htm -- 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: quota on raid
On Sat, Feb 18, 2006 at 02:30:47PM +0100, Antonello PAPA wrote: At 09.49 18/02/06, you wrote: On Sat, Feb 18, 2006 at 09:42:04AM +0100, Luca Berra wrote: On Sat, Feb 18, 2006 at 02:12:26AM +0100, Antonello PAPA wrote: i have two disk with raid 1. i can't find documents on how to set the quotas. i whould like to set the quota on /home, can some opne help? thanks and sorry for bad english. antonello in italian: http://www.lnf.infn.it/computing/doc/AppuntiLinux/a296.html sorry, this is the _current_ version http://a2.swlibero.org/a2111.htm i have used that document but it doesn't work. This is my fstab: /dev/md1 / ext3defaults1 1 /dev/md0 /bootext3defaults1 2 /dev/devpts /dev/pts devpts gid=5,mode=620 0 0 /dev/shm /dev/shm tmpfs defaults0 0 /dev/md5 /home ext3, usrquota, grpquota defaults1 2 which is _not_ what the document instructs you to. read it again. in any case, configuring disk quotas is not the object of this mailing list. it does not matter if you want to configure quotas on raid, quotas are a filesystem feature, not a block device feature. that said, you don't give any hint about your problem. please take some time to read http://xoomer.virgilio.it/army1987k before posting again. 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: Bigendian issue with mdadm
On Tue, Feb 21, 2006 at 10:44:22AM +1100, Neil Brown wrote: On Monday February 20, [EMAIL PROTECTED] wrote: Hi All, Please, Help ! I've created a raid5 array on a x86 platform, and now wish to use it on a mac mini (g4 based). But the problem is : the first is little-endian, the second big-endian... And it seams like md superblock disk format is hostendian, so how should I say mdadm to use a endianness ? Read the man page several times? Look for --update=byteorder You need mdadm-2.0 or later. besides IIRC version 1 super block is always little-endan. 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: raid5 wont restart after disk failure, then corrupts
On Tue, Feb 28, 2006 at 10:08:11PM +, Chris Allen wrote: Yesterday morning we had an io error on /dev/sdd1: Feb 27 10:08:57 snap25 kernel: SCSI error : 0 0 3 0 return code = 0x1 Feb 27 10:08:57 snap25 kernel: end_request: I/O error, dev sdd, sector 50504271 Feb 27 10:08:57 snap25 kernel: raid5: Disk failure on sdd1, disabling device. Operation continuing on 7 devices So, I shutdown the system and replaced drive sdd with a new one. When I powered up again, all was not well. The array wouldn't start: Feb 27 13:36:02 snap25 kernel: md: md0: raid array is not clean -- starting background reconstruction Feb 27 13:36:02 snap25 kernel: raid5: cannot start dirty degraded array for md0 something happened whan you shut down the system and the superblock on the drives was not updated I tried assembling the array with --force, but this would produce exactly the same results as above - the array would refuse to start. QUESTION: What should I have done here? Each time I have tried this in the past, I recreate the array with a missing drive in place of sdd. mount your fs readonly (as ext2 in case it was ext3) and verify that all data is readable. have had no problems restarting the array and adding the new disk. What had gone wrong, and why wouldn't the array start? something happened whan you shut down the system and the superblock on the drives was not updated Then things went from bad to worse. === PROBLEM 2 - DATA CORRUPTION === 1. Any idea what had happened here? Why didn't it notice that sdd1 was stale? something happened whan you shut down the system and the superblock on the drives was not updated 2. If I had let it complete its resync would it have sorted out the corruption? no Or would it have made things worse? possibly yes 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: Bitmaps Kernel Versions
On Wed, Mar 15, 2006 at 09:08:17PM +1100, Neil Brown wrote: On Wednesday March 15, [EMAIL PROTECTED] wrote: Hi, I'm planning to use bitmaps on some of our RAID1 arrays. I'm wondering how bitmaps are handeled by older kernels. Eg: I create a raid array with a bitmap under a 2.6.15 kernel. I now want to boot under 2.6.12, or even 2.4 Hos is it handeled? Will it work even if this is my / partition? On older kernel will not notice the bitmap and will behave 'normally'. strange, last time i tried an older kernel would refuse to activate an md with a bitmap on it. I am far from home on a business trip and i don't have kernel-sources at hand, but i seem to remember that the kernel was very strict on the feature bitmap in the superblock. 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: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
On Sun, Apr 09, 2006 at 02:35:53PM +0200, Marc L. de Bruin wrote: Hi, (I just subscribed, sorry if this is a dupe. I did try to match the subject from the archives, but couldn't find any...) I ran into trouble after upgrading a Debian Sarge system from 2.6.11 to 2.6.15. To be more precise, it turned out that md/mdadm seems to not function properly during the boot process of 2.6.15. My /etc/mdadm/mdadm.conf contains this: ---[mdadm.conf]--- DEVICE /dev/hdi1 /dev/hdg1 /dev/hdc1 ARRAY /dev/md1 level=raid5 num-devices=3 UUID=09c58ab6:f706e37b:504cf890:1a597046 devices=/dev/hdi1,/dev/hdg1,/dev/hdc1 DEVICE /dev/hdg2 /dev/hdc2 ARRAY /dev/md2 level=raid1 num-devices=2 UUID=86210844:6abbf533:dc82f982:fe417066 devices=/dev/hdg2,/dev/hdc2 DEVICE /dev/hda2 /dev/hdb2 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=da619c37:6c072dc8:52e45423:f4a58b7c devices=/dev/hda2,/dev/hdb2 DEVICE /dev/hda1 /dev/hdb1 ARRAY /dev/md4 level=raid1 num-devices=2 UUID=bfc30f9b:d2c21677:c4ae5f90:b2bddb75 devices=/dev/hda1,/dev/hdb1 DEVICE /dev/hdc3 /dev/hdg3 ARRAY /dev/md3 level=raid1 num-devices=2 UUID=fced78ce:54f00a78:8662e7eb:2ad01d0b devices=/dev/hdc3,/dev/hdg3 ---[/mdadm.conf]--- replace all DEVICE . lines with a single DEVICE partitions remove all the device=... part from the array lines. L. - 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] forcing a read on a known bad block
On Tue, Apr 11, 2006 at 12:37:53PM -1000, Julian Cowley wrote: On Tue, 11 Apr 2006, dean gaudet wrote: anyhow this made me wonder if there's some other existing trick to force such reads/reconstructions to occur... or perhaps this might be a useful future feature. For testing RAID, what would be really nice is if there were a virtual disk device where one could simulate bad sectors (read or write), non-responsive disks, etc. It would be virtual in the same sort way that /dev/full simulates a full disk. either use the MD faulty personality, or the device-mapper error target. 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: EVMS causing problems with mdadm?
On Mon, Apr 24, 2006 at 07:48:00AM +1000, Neil Brown wrote: On Sunday April 23, [EMAIL PROTECTED] wrote: Did my latest updates for my Kubuntu (Ubuntu KDE variant) this morning, and noticed that EVMS has now taken control of my RAID array. Didn't think much about it until I tried to make a RAID-1 array with two disks I've just added to the system. Trying to do a create verbose tells me that device /dev/md1 (or 2 or 3 - I tried a couple just to see) doesn't exist. And in fact, there are no block devices listed beyond md0. Sounds like udev is in use rather than a static /dev. Add '--auto=md' to the mdadm command line, and it will create the devices for you. Or --auto=part if you want partitioned arrays. See man page for more details. I suspect this might need to be come the default in another year or so i was tkinking about stat()ing /dev/.udev and automatically enabling --auto if found WDYT? 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: slackware -current softraid5 boot problem
On Tue, May 09, 2006 at 12:06:32AM +0200, Dexter Filmore wrote: Finally got me a bunch of disks as a raid 5, I don't even want to boot from it, plain data array. four sata-II samsungs on a sil3114 controller, all fine so far. Booting the machine I get no superblock on /dev/sdd, stopping assembly (or assembly aborted or so) After boot has completed, running mdadm --assemble --scan --verbose manually works just fine and doesn't tell a thing about missing superblocks. you don't give a lot of information about your setup, in any case it could be something like udev and the /dev/sdd device node not being available at boot? 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: strange RAID5 problem
On Mon, May 08, 2006 at 11:30:52PM -0600, Maurice Hilarius wrote: [EMAIL PROTECTED] ~]# mdadm /dev/md3 -a /dev/sdw1 But, I get this error message: mdadm: hot add failed for /dev/sdw1: No such device What? We just made the partition on sdw a moment ago in fdisk. It IS there! I don't believe you, prove it (/proc/partitions) So. we look around a bit: # /cat/proc/mdstat md3 : inactive sdq1[0] sdaf1[15] sdae1[14] sdad1[13] sdac1[12] sdab1[11] sdaa1[10] sdz1[9] sdy1[8] sdx1[7] sdv1[5] sdu1[4] sdt1[3] sds1[2] sdr1[1] 5860631040 blocks Yup, that looks correct, missing sdw1[6] no, it does not, it is 'inactive' [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid1] [raid5] ... md3 : inactive sdq1[0] sdaf1[15] sdae1[14] sdad1[13] sdac1[12] sdab1[11] sdaa1[10] sdz1[9] sdy1[8] sdx1[7] sdv1[5] sdu1[4] sdt1[3] sds1[2] sdr1[1] 5860631040 blocks ... [EMAIL PROTECTED] ~]# mdadm /dev/md3 -a /dev/sdw1 mdadm: hot add failed for /dev/sdw1: No such device OK, let's mount the degraded RAID and try to copy the files to somewhere else, so we can make it from scratch: [EMAIL PROTECTED] ~]# mount /dev/md3 /all/boxw16/ /dev/md3: Invalid argument mount: /dev/md3: can't read superblock it is still inactive, no wonder you cannot access it. try running the array, or really stop it before assembling. 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: strange RAID5 problem
On Tue, May 09, 2006 at 10:16:25AM -0600, Maurice Hilarius wrote: Luca Berra wrote: On Mon, May 08, 2006 at 11:30:52PM -0600, Maurice Hilarius wrote: [EMAIL PROTECTED] ~]# mdadm /dev/md3 -a /dev/sdw1 But, I get this error message: mdadm: hot add failed for /dev/sdw1: No such device What? We just made the partition on sdw a moment ago in fdisk. It IS there! I don't believe you, prove it (/proc/partitions) I understand. Here we go then. Devices in question bracketed with **: ok, now i do. is the /dev/sdw1 device file correctly created? you could try straceing mdadm to see what happens what about the other suggestion? trying to stop the array and restart it, since it is marked as inactive. 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: problems with raid=noautodetect
On Tue, May 23, 2006 at 08:39:26AM +1000, Neil Brown wrote: Presumably you have a 'DEVICE' line in mdadm.conf too? What is it. My first guess is that it isn't listing /dev/sdd? somehow. Neil, i am seeing a lot of people that fall in this same error, and i would propose a way of avoiding this problem 1) make DEVICE partitions the default if no device line is specified. 2) deprecate the DEVICE keyword issuing a warning when it is found in the configuration file 3) introduce DEVICEFILTER or similar keyword with the same meaning at the actual DEVICE keyboard 4) optionally add an EXCLUDEDEVICE keyword with the opposite meaning. 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: problems with raid=noautodetect
On Fri, May 26, 2006 at 09:53:08AM +0200, Luca Berra wrote: On Tue, May 23, 2006 at 08:39:26AM +1000, Neil Brown wrote: Presumably you have a 'DEVICE' line in mdadm.conf too? What is it. My first guess is that it isn't listing /dev/sdd? somehow. Neil, i am seeing a lot of people that fall in this same error, and i would propose a way of avoiding this problem 1) make DEVICE partitions the default if no device line is specified. oops, just read your 2.5 announce, you already did that :) 2) deprecate the DEVICE keyword issuing a warning when it is found in the configuration file 3) introduce DEVICEFILTER or similar keyword with the same meaning at the actual DEVICE keyboard 4) optionally add an EXCLUDEDEVICE keyword with the opposite meaning. -- 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: RAID5 kicks non-fresh drives
On Fri, May 26, 2006 at 11:06:21AM -0600, Craig Hollabaugh wrote: On Fri, 2006-05-26 at 12:45 -0400, Mark Hahn wrote: I think the current situation is good, since there is some danger of going too far. for instance, testing each partition to see whether it contains a valid superblock would be pretty crazy, right? requiring either the auto-assemble-me partition type, or explicit partitions given in a config file is a happy medium... I created my array in 1/2003, don't know versions of kernel or mdadm I was using then. In my situation over the past few days. kernel 2.4.30 kicked non-fresh kernel 2.6.11.8 kicked non-fresh kernel 2.6.18.8 didn't mention anything, just skipped my 'linux' partitions These kernels auto-assemble prior to mounting /. So the kernel doesn't consult my /etc/mdadm/mdadm.conf file. Is this correct? i strongly believe it is not correct to let kernel auto-assemble devices kernel auto-assembly should be disable and activation should be handled by mdadm only! 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: RAID5 kicks non-fresh drives
On Fri, May 26, 2006 at 03:37:29PM -0400, Mark Hahn wrote: i strongly believe it is not correct to let kernel auto-assemble devices kernel auto-assembly should be disable and activation should be handled by mdadm only! it's a convenience/safety tradeoff, like so many other cases. without kernel auto-assembly, it's somewhat more annoying to boot onto MD raid, right? you are forced to put MD config stuff into your initrd, etc. yes, it is, but initrd are generated by scripts nowadays, so you wont even notice. I don't see why auto-assembly is such a bad thing. it means you please read the list archives, it has been explained to boredom the only argument I see against (kernel) auto-assembly is the general principle of moving things out of the kernel where possible. but that's not a hard/fast rule anyway, so... please read the list archives, it has been explained to boredom Regards, L. and please, do not To: or Cc: me, i do actively read the list. 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: [patch] install a static build
On Sat, May 27, 2006 at 12:08:19PM +0200, Dirk Jagdmann wrote: Hello developers, after building my static mdadm I wanted to install it via make install, but had to tweak the Makefile a little. However my approach is not the best, since I had to remove the rmconf target for the static build, issue a cp of the mdadm.static binary and my patch might interfere with the everything target :-( maybe you better add an install-static target. 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: [patch] fix static build
On Sat, May 27, 2006 at 12:05:56PM +0200, Dirk Jagdmann wrote: Hello developers and patch reviewers, I just tried to update my (old) mdadm to 2.5 and had to apply this small patch to build a static linked mdadm. you should also fix the clean target. 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
[PATCH] mdadm 2.5 (Was: ANNOUNCE: mdadm 2.5 - A tool for managing Soft RAID under Linux)
On Fri, May 26, 2006 at 04:33:08PM +1000, Neil Brown wrote:
I am pleased to announce the availability of
mdadm version 2.5
hello,
i tried rebuilding mdadm 2.5 on current mandriva cooker, which uses
gcc-4.1.1, glibc-2.4 and dietlibc 0.29 and found the following issues
addressed by patches attacched to this message
I would be glad if you could review these patches and include them in
upcoming mdadm releases.
- mdadm-2.3.1-kernel-byteswap-include-fix.patch
reverts a change introduced with mdadm 2.3.1 for redhat compatibility
asm/byteorder.h is an architecture dependent file and does more
stuff than a call to the linux/byteorder/XXX_endian.h
the fact that not calling asm/byteorder.h does not define
__BYTEORDER_HAS_U64__ is just an example of issues that might arise.
if redhat is broken it should be worked around differently than breaking
mdadm.
- mdadm-2.4-snprintf.patch
this is self commenting, just an error in the snprintf call
- mdadm-2.4-strict-aliasing.patch
fix for another srict-aliasing problem, you can typecast a reference to a
void pointer to anything, you cannot typecast a reference to a struct.
- mdadm-2.5-mdassemble.patch
pass CFLAGS to mdassemble build, enabling -Wall -Werror showed some
issues also fixed by the patch.
- mdadm-2.5-rand.patch
Posix dictates rand() versus bsd random() function, and dietlibc
deprecated random(), so switch to srand()/rand() and make everybody
happy.
- mdadm-2.5-unused.patch
glibc 2.4 is pedantic on ignoring return values from fprintf, fwrite and
write, so now we check the rval and actually do something with it.
in the Grow.c case i only print a warning, since i don't think we can do
anithing in case we fail invalidating those superblocks (is should never
happen, but then...)
Regards,
L.
--
Luca Berra -- [EMAIL PROTECTED]
Communication Media Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
XAGAINST HTML MAIL
/ \
* Sat Feb 18 2006 Christiaan Welvaart [EMAIL PROTECTED]
not including asm/byteorder.h will not define __BYTEORDER_HAS_U64__
causing __fswab64 to be undefined and failure compiling mdadm on
big_endian architectures like PPC
--- mdadm-2.3.1/mdadm.h.bak 2006-02-06 04:52:12.0 +0100
+++ mdadm-2.3.1/mdadm.h 2006-02-18 03:51:59.786926267 +0100
@@ -72,16 +72,7 @@
#include bitmap.h
#include endian.h
-/* #include asm/byteorder.h Redhat don't like this so... */
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-# include linux/byteorder/little_endian.h
-#elif __BYTE_ORDER == __BIG_ENDIAN
-# include linux/byteorder/big_endian.h
-#elif __BYTE_ORDER == __PDP_ENDIAN
-# include linux/byteorder/pdp_endian.h
-#else
-# error unknown endianness.
-#endif
+#include asm/byteorder.h
* Sat May 27 2006 Luca Berra [EMAIL PROTECTED]
snprintf size should be at most the size of the buffer
--- mdadm-2.4/util.c.snprintf 2006-05-27 13:53:18.0 +0200
+++ mdadm-2.4/util.c2006-05-27 13:53:38.0 +0200
@@ -439,7 +439,7 @@
}
if (create !std !nonstd) {
static char buf[30];
- snprintf(buf, 1024, %d:%d, major, minor);
+ snprintf(buf, 30, %d:%d, major, minor);
nonstd = buf;
}
* Sat May 27 2006 Luca Berra [EMAIL PROTECTED]
This is to avoid gcc warnings when building with strict-aliasing optimization
--- mdadm-2.4/dlink.h.alias 2006-05-26 21:05:07.0 +0200
+++ mdadm-2.4/dlink.h 2006-05-27 12:32:58.0 +0200
@@ -4,16 +4,16 @@
struct __dl_head
{
-struct __dl_head * dh_prev;
-struct __dl_head * dh_next;
+void * dh_prev;
+void * dh_next;
};
#definedl_alloc(size) ((void*)(((char*)calloc(1,(size)+sizeof(struct
__dl_head)))+sizeof(struct __dl_head)))
#definedl_new(t) ((t*)dl_alloc(sizeof(t)))
#definedl_newv(t,n)((t*)dl_alloc(sizeof(t)*n))
-#define dl_next(p) *((void**)(((struct __dl_head*)(p))[-1].dh_next))
-#define dl_prev(p) *((void**)(((struct __dl_head*)(p))[-1].dh_prev))
+#define dl_next(p) *struct __dl_head*)(p))[-1].dh_next))
+#define dl_prev(p) *struct __dl_head*)(p))[-1].dh_prev))
void *dl_head(void);
char *dl_strdup(char *);
* Sat May 27 2006 Luca Berra [EMAIL PROTECTED]
add CFLAGS to mdassemble build and fix a couple of non-returning functions
--- mdadm-2.5/mdadm.h.bluca 2006-05-27 14:25:53.0 +0200
+++ mdadm-2.5/mdadm.h 2006-05-27 15:20:37.0 +0200
@@ -44,10 +44,8 @@
#include errno.h
#include string.h
#include syslog.h
-#ifdef __dietlibc__NONO
-int strncmp(const char *s1, const char *s2, size_t n) __THROW __pure__;
-char *strncpy(char *dest, const char *src, size_t n) __THROW;
-#includestrings.h
+#ifdef __dietlibc__
+#include strings.h
#endif
--- mdadm-2.5/mdassemble.c.bluca2006-05-27 15:11:02.0 +0200
+++ mdadm-2.5/mdassemble.c 2006-05-27 15:15:24.0 +0200
@@ -54,7 +54,7 @@
};
#ifndef MDASSEMBLE_AUTO
-/* from mdadm.c */
+/* from mdopen.c */
int
Re: [PATCH] mdadm 2.5 (Was: ANNOUNCE: mdadm 2.5 - A tool for managing Soft RAID under Linux)
On Sun, May 28, 2006 at 10:08:19AM -0700, dean gaudet wrote: On Sun, 28 May 2006, Luca Berra wrote: - mdadm-2.5-rand.patch Posix dictates rand() versus bsd random() function, and dietlibc deprecated random(), so switch to srand()/rand() and make everybody happy. fwiw... lots of rand()s tend to suck... and RAND_MAX may not be large enough for this use. glibc rand() is the same as random(). do you know the fact that glibc rand() is the same implementation as random() was one of the reason i believe we could switch to rand() if dietlibc's rand() is good enough? dietlibc rand() and random() are the same function. but random will throw a warning saying it is deprecated. 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: problems with raid=noautodetect
On Mon, May 29, 2006 at 02:21:09PM +1000, Neil Brown wrote: 3) introduce DEVICEFILTER or similar keyword with the same meaning at the actual DEVICE keyboard If it has the same meaning, why not leave it called 'DEVICE'??? the idea was to warn people that write DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 ARRAY /dev/md0 ... that it might break since disk naming is not guaranteed to be constant. However, there is at least the beginnings of a good idea here. If we assume there is a list of devices provided by a (possibly default) 'DEVICE' line, then DEVICEFILTER !pattern1 !pattern2 pattern3 pattern4 could mean that any device in that list which matches pattern 1 or 2 is immediately discarded, and remaining device that matches patterns 3 or 4 are included, and the remainder are discard. The rule could be that the default is to include any devices that don't match a !pattern, unless there is a pattern without a '!', in which case the default is to reject non-accepted patterns. Is that straight forward enough, or do I need an order allow,deny like apache has? I think that documenting the feature would be enough 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: [PATCH] mdadm 2.5 (Was: ANNOUNCE: mdadm 2.5 - A tool for managing Soft RAID under Linux)
On Mon, May 29, 2006 at 12:08:25PM +1000, Neil Brown wrote: On Sunday May 28, [EMAIL PROTECTED] wrote: Thanks for the patches. They are greatly appreciated. You're welcome - mdadm-2.3.1-kernel-byteswap-include-fix.patch reverts a change introduced with mdadm 2.3.1 for redhat compatibility asm/byteorder.h is an architecture dependent file and does more stuff than a call to the linux/byteorder/XXX_endian.h the fact that not calling asm/byteorder.h does not define __BYTEORDER_HAS_U64__ is just an example of issues that might arise. if redhat is broken it should be worked around differently than breaking mdadm. I don't understand the problem here. What exactly breaks with the code currently in 2.5? mdadm doesn't need __BYTEORDER_HAS_U64__, so why does not having id defined break anything? The coomment from the patch says: not including asm/byteorder.h will not define __BYTEORDER_HAS_U64__ causing __fswab64 to be undefined and failure compiling mdadm on big_endian architectures like PPC But again, mdadm doesn't use __fswab64 More details please. you use __cpu_to_le64 (ie in super0.c line 987) bms-sync_size = __cpu_to_le64(size); which in byteorder/big_endian.h is defined as #define __cpu_to_le64(x) ((__force __le64)__swab64((x))) but __swab64 is defined in byteorder/swab.h (included by byteorder/big_endian.h) as #if defined(__GNUC__) (__GNUC__ = 2) defined(__OPTIMIZE__) # define __swab64(x) \ (__builtin_constant_p((__u64)(x)) ? \ ___swab64((x)) : \ __fswab64((x))) #else # define __swab64(x) __fswab64(x) #endif /* OPTIMIZE */ and __fswab64 is defined further into byteorder/swab.h as #ifdef __BYTEORDER_HAS_U64__ static __inline__ __attribute_const__ __u64 __fswab64(__u64 x) . #endif /* __BYTEORDER_HAS_U64__ */ so building mdadm on a ppc (or i suppose a sparc) will break now, if you look at /usr/src/linux/asm-*/byteorder.h you will notice they are very different files, this makes me believe it is not a good idea bypassing asm/byteorder.h And no, just defining __BYTEORDER_HAS_U64__ will break on 32bit big-endian cpus (and if i do not misread it might just compile and give incorrect results) - mdadm-2.4-snprintf.patch this is self commenting, just an error in the snprintf call I wonder how that snuck in... There was an odd extra tab in the patch, but no-matter. I changed it to use 'sizeof(buf)' to be consistent with other uses of snprint. Thanks. yes, that would be better. - mdadm-2.4-strict-aliasing.patch fix for another srict-aliasing problem, you can typecast a reference to a void pointer to anything, you cannot typecast a reference to a struct. Why can't I typecast a reference to a struct??? It seems very unfair... that's strict-aliasing optimization for you, i do agree it _is_ unfair. However I have no problem with the patch. Applied. Thanks. I should really change it to use 'list.h' type lists from the linux kernel. hopefull redhat would not object :) - mdadm-2.5-mdassemble.patch pass CFLAGS to mdassemble build, enabling -Wall -Werror showed some issues also fixed by the patch. yep, thanks. - mdadm-2.5-rand.patch Posix dictates rand() versus bsd random() function, and dietlibc deprecated random(), so switch to srand()/rand() and make everybody happy. Everybody? 'man 3 rand' tells me: Do not use this function in applications intended to be portable when good randomness is needed. Admittedly mdadm doesn't need to be portable - it only needs to run on Linux. But this line in the man page bothers me. I guess -Drandom=rand -Dsrandom=srand might work no. stdlib.h doesn't like that. 'random' returns 'long int' while rand returns 'int'. Interestingly 'random_r' returns 'int' as does 'rand_r'. #ifdef __dietlibc__ #includestrings.h /* dietlibc has deprecated random and srandom!! */ #define random rand #define srandom srand #endif in mdadm.h. Will that do you? yes, mdassemble will build, so it is ok for me. - mdadm-2.5-unused.patch glibc 2.4 is pedantic on ignoring return values from fprintf, fwrite and write, so now we check the rval and actually do something with it. in the Grow.c case i only print a warning, since i don't think we can do anithing in case we fail invalidating those superblocks (is should never happen, but then...) Ok, thanks. You can see these patches at http://neil.brown.name/cgi-bin/gitweb.cgi?p=mdadm Thanks. -- 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: problems with raid=noautodetect
On Mon, May 29, 2006 at 12:38:25PM +0400, Michael Tokarev wrote: Neil Brown wrote: On Friday May 26, [EMAIL PROTECTED] wrote: I'd suggest the following. All the other devices are included or excluded from the list of devices to consider based on the last component in the DEVICE line. Ie. if it ends up at !dev, all the rest of devices are included. If it ends up at dev (w/o !), all the rest are excluded. If memory serves me right, it's how squid ACLs works. There's no need to introduce new keyword. Given this rule, a line as i said the new keyword is to warn on configurations that do not account for changing device-ids, and if we change the syntax a new keyword would make it clearer. In case the user tries to use a new configuration on an old mdadm. The only possible issue I see here is that with udev, it's possible to use, say, /dev/disk/by-id/*-like stuff (don't remember exact directory layout) -- symlinked to /dev/sd* according to the disk serial number or something like that -- for this to work, mdadm needs to use glob() internally. uhm i think that we would better translate any device found on a DEVICE (or DEVICEFILTER) line to the corresponding major/minor number and blacklist based on that. nothing prevents someone to have an udev rule that creates a device node, instead of symlinking. 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: problems with raid=noautodetect
On Tue, May 30, 2006 at 01:10:24PM -0400, Bill Davidsen wrote: 2) deprecate the DEVICE keyword issuing a warning when it is found in the configuration file Not sure I'm so keen on that, at least not in the near term. Let's not start warning and depreciating powerful features because they can be misused... If I wanted someone to make decisions for me I would be using this software at all. you cut the rest of the mail. i did not propose to deprecate the feature, just the keyword. but, ok, just go on writing DEVICE /dev/sda1 DEVICE /dev/sdb1 ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1 then come on the list and complain when it stops working. 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: adding multipath device without reboot?
On Tue, May 30, 2006 at 03:59:33PM +0200, Herta Van den Eynde wrote: I'm trying to add a new SAN LUN to a system, create a multipath mdadm device on it, partition it, and create a new filesystem on it, all without taking the system down. All goes well, up to partitioning the md device: # fdisk /dev/md12 wait! you cannot partition an md device. if you need you have to use an mdp device, but do you? if you just want to create a single filesystem, as you do below, use the md device directly. 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: Failed Hard Disk... help!
On Fri, Jun 09, 2006 at 07:44:40PM -0400, David M. Strang wrote: /Patrick wrote: pretty sure smartctl -d ata -a /dev/sdwhatever will tell you the serial number. (Hopefully the kernel is new enough that it supports SATA/smart, otherwise you need a kernel patch which won't be any better...) Yep... 2.6.15 or better... I need the magical patch =\. Any other options? scsi_id from udev, if you are lucky enough 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: [PATCH*2] mdadm works with uClibc from SVN
On Fri, Jun 23, 2006 at 08:45:47PM +0100, Nix wrote: On Fri, 23 Jun 2006, Neil Brown mused: Is there some #define in an include file which will allow me to tell if the current uclibc supports ftw or not? it is not only depending on the uClibc version, but also if ftw support was compiled in or not. I misspoke: ftw was split into multiple files in late 2005, but it was originally added in September 2003, in time for version 0.9.21. Obviously the #defines in ftw.h don't exist before that date, but that's a bit late to check, really. features.h provides the macros __UCLIBC_MAJOR__, __UCLIBC_MINOR__, and __UCLIBC_SUBLEVEL__: versions above 0.9.20 appear to support ftw() (at least, they have the function, in 32-bit form at least, which is certainly enough for this application!) the following would be the correct check. #include features.h #ifdef __UCLIBC_HAS_FTW__ . #else . #endif /* __UCLIBC_HAS_FTW__ */ -- 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
[PATCH] enable auto=yes by default when using udev
Hello,
the following patch aims at solving an issue that is confusing a lot of
users.
when using udev, device files are created only when devices are
registered with the kernel, and md devices are registered only when
started.
mdadm needs the device file _before_ starting the array.
so when using udev you must add --auto=yes to the mdadm commandline or
to the ARRAY line in mdadm.conf
following patch makes auto=yes the default when using udev
L.
--
Luca Berra -- [EMAIL PROTECTED]
Communication Media Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
XAGAINST HTML MAIL
/ \
* Sat Jun 24 2006 Luca Berra [EMAIL PROTECTED]
- automatically create devices if using udev
--- mdadm-2.5.1/mdadm.c.autof 2006-06-02 01:51:01.0 -0400
+++ mdadm-2.5.1/mdadm.c 2006-06-24 05:17:45.0 -0400
@@ -857,6 +857,13 @@
fputs(Usage, stderr);
exit(2);
}
+
+ /* if we are using udev and auto is not set, mdadm will almost
+* certainly fail, so we force it here.
+*/
+ if (autof == 0 access(/dev/.udevdb,F_OK) == 0)
+ autof=2;
+
/* Ok, got the option parsing out of the way
* hopefully it's mostly right but there might be some stuff
* missing
@@ -873,7 +880,7 @@
fprintf(stderr, Name : an md device must be given in
this mode\n);
exit(2);
}
- if ((int)ident.super_minor == -2 autof) {
+ if ((int)ident.super_minor == -2 autof 2 ) {
fprintf(stderr, Name : --super-minor=dev is
incompatible with --auto\n);
exit(2);
}
Re: [PATCH] enable auto=yes by default when using udev
On Mon, Jul 03, 2006 at 09:14:38AM +1000, Neil Brown wrote: However + + /* if we are using udev and auto is not set, mdadm will almost +* certainly fail, so we force it here. +*/ + if (autof == 0 access(/dev/.udevdb,F_OK) == 0) + autof=2; + I'm worried that this test is not very robust. On my Debian/unstable system running used, there is no /dev/.udevdb though there is a /dev/.udev/db I guess I could test for both, but then udev might change again I'd really like a more robust check. is /dev/.udev/db a debianism? in this case a check for both might suffice, else i will have to think harder about it. 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: [PATCH] enable auto=yes by default when using udev
On Tue, Jul 04, 2006 at 12:46:03AM +0200, Luca Berra wrote: On Mon, Jul 03, 2006 at 09:14:38AM +1000, Neil Brown wrote: However + + /* if we are using udev and auto is not set, mdadm will almost +* certainly fail, so we force it here. +*/ + if (autof == 0 access(/dev/.udevdb,F_OK) == 0) + autof=2; + I'm worried that this test is not very robust. On my Debian/unstable system running used, there is no /dev/.udevdb though there is a /dev/.udev/db I guess I could test for both, but then udev might change again I'd really like a more robust check. is /dev/.udev/db a debianism? no it is not in this case a check for both might suffice, else i will have to think harder about it. -- 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
issue with internal bitmaps
hello, i just realized that internal bitmaps do not seem to work anymore. kernel 2.6.17 mdadm 2.5.2 [EMAIL PROTECTED] ~]# mdadm --create --level=1 -n 2 -e 1 --bitmap=internal /dev/md100 /dev/sda1 /dev/sda2 mdadm: array /dev/md100 started. ... wait awhile ... [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid1] md100 : active raid1 sda2[1] sda1[0] 1000424 blocks super 1.0 [2/2] [UU] bitmap: 4/4 pages [16KB], 128KB chunk unused devices: none [EMAIL PROTECTED] ~]# mdadm -X /dev/md100 Filename : /dev/md100 Magic : mdadm: invalid bitmap magic 0x0, the bitmap file appears to be corrupted Version : 0 mdadm: unknown bitmap version 0, either the bitmap file is corrupted or you need to upgrade your tools [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid1] md100 : active raid1 sda2[1] sda1[0] 1000424 blocks super 1.0 [2/2] [UU] bitmap: 0/4 pages [0KB], 128KB chunk unused devices: none [EMAIL PROTECTED] ~]# mdadm -D /dev/md100 /dev/md100: Version : 01.00.03 Creation Time : Thu Jul 6 16:05:10 2006 Raid Level : raid1 Array Size : 1000424 (977.14 MiB 1024.43 MB) Device Size : 1000424 (977.14 MiB 1024.43 MB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 100 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Thu Jul 6 16:07:11 2006 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : 100 UUID : 60cd0dcb:fde52377:699453f7:da96b9d4 Events : 1 Number Major Minor RaidDevice State 0 810 active sync /dev/sda1 1 821 active sync /dev/sda2 -- 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: issue with internal bitmaps
On Fri, Jul 07, 2006 at 08:16:18AM +1000, Neil Brown wrote: On Thursday July 6, [EMAIL PROTECTED] wrote: hello, i just realized that internal bitmaps do not seem to work anymore. I cannot imagine why. Nothing you have listed show anything wrong with md... Maybe you were expecting mdadm -X /dev/md100 to do something useful. Like -E, -X must be applied to a component device. Try mdadm -X /dev/sda1 /me needs some strong coffe. yes you are right, sorry 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: issue with internal bitmaps
On Tue, Jul 18, 2006 at 09:34:35AM -0400, Bill Davidsen wrote: Boy, I didn't say that well... what I meant to suggest is that when -E or -X are applied to the array as a whole, would it not be useful to itterate them over all of the components rather than than looking for non-existant data in the array itself? the question i believe is to distinguish the case where an md device is a component of another md device... 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: host based mirror distance in a fc-based SAN environment
On Wed, Jul 26, 2006 at 07:58:09AM +0200, Stefan Majer wrote: Hi, im curious if there are some numbers out up to which distance its possible to mirror (raid1) 2 FC-LUNs. We have 2 datacenters with a effective distance of 11km. The fabrics in one datacenter are connected to the fabrics in the other datacenter with 5 dark fibre both about 11km in distance. as you probably already know with LX (1310nm) GBICS and single-mode fiber you can reach up to a theoretical limit of 50Km, and you can double that using 1550 nm lasers (ZX?) I want to set up servers wich mirrors their LUNs across the SAN-boxen in both datacenters. On top of this mirrored LUN i put lvm2. So the question is does anybody have some numbers up to which distance this method works ? the method is independent of the distance, if your FC hardware can do that, then you can. the only thing you should consider (and that is not directly related to distance) is the bandwith you have between the two sites (i mean the number of systems that might be using those 5 fibers) 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: let md auto-detect 128+ raid members, fix potential race condition
On Tue, Aug 01, 2006 at 05:46:38PM -0300, Alexandre Oliva wrote: Using the mkinitrd patch that I posted before, the result was that mdadm did try to bring up all raid devices but, because the raid456 module was not loaded in initrd, the raid devices were left inactive. probably your initrd is broken, it should not have even tried to bring up an md array that was not needed to mount root. Then, when rc.sysinit tried to bring them up with mdadm -A -s, that did nothing to the inactive devices, since they didn't have to be assembled. Adding --run didn't help. My current work-around is to add raid456 to initrd, but that's ugly. Scanning /proc/mdstat for inactive devices in rc.sysinit and doing mdadm --run on them is feasible, but it looks ugly and error-prone. Would it be reasonable to change mdadm so as to, erhm, disassemble ;-) the raid devices it tried to bring up but that, for whatever reason, it couldn't activate? (say, missing module, not enough members, whatever) this would make sense if it were an option, patches welcome :) 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: let md auto-detect 128+ raid members, fix potential race condition
On Tue, Aug 01, 2006 at 06:32:33PM -0300, Alexandre Oliva wrote: Sure enough the LVM subsystem could make things better for one to not need all of the PVs in the root-containing VG in order to be able to mount root read-write, or at all, but if you think about it, if initrd it shouldn't need all of the PVs you just need all the pv where the rootfs is. is set up such that you only bring up the devices that hold the actual root device within the VG and then you change that, say by taking a snapshot of root, moving it around, growing it, etc, you'd be better off if you could still boot. So you do want all of the VG members to be around, just in case. in this case just regenerate the initramfs after modifying the vg that contains root. I am fairly sure that kernel upgrades are far more frequent than the addirion of PVs to the root VG. Yes, this is an argument against root on LVM, but there are arguments *for* root on LVM as well, and there's no reason to not support both behaviors equally well and let people figure out what works best for them. No, this is just an argument against misusing root on lvm. 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: resize new raid problem
On Wed, Aug 09, 2006 at 01:55:56PM +0400, Serge Torop wrote: I need to install softw. RAID1 to working RedHat EL4. I used rescue mode for creating RAID arrays. ... resize2fs /dev/md2 and see a error messge: resize2fs 1.39 /resize2fs: relocation error: - /resize2fs: undefined symbol: ext2fs_open2 Can I resolve this problem (resize2fs bug?)? (may be using mdadm?) since you bought a commercial product from redhat you might be better open a support call to them. if the resize2fs binary you are using comes from EL4, that is. 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: Making bootable SATA RAID1 array in Mandriva 2006
On Sun, Aug 13, 2006 at 07:51:42PM -0400, andy liebman wrote: -- I copied the contents of /dev/sda1 (/ partition) and /dev/sda6 (/home partition) to /dev/sdb1 and /dev/sdb6 using rsync. this is not really important, but you should have used the raid devices as a target. -- I edited fstab and lilo.conf on the the RAID1 / partition so that they would refer to /dev/md1 -- I ran chroot on the /dev/md1 partition did you mount /dev, /proc and /sys before chrooting? i.e mount --bind /dev /newroot/dev mount -t proc /proc /newroot/proc mount -t sysfs /sys /newroot/sys -- I set up an /etc/mdadm.conf file (using mdadm --detail --scan/etc/mdadm.conf -- that's where Mandriva puts it) -- I added to lilo.conf raid-extra-boot= and tried both mbr and /dev/sda,/dev/sdb mbr should do -- I ran mkinitrd and created a new initrd in /boot on /dev/md1. I got an error about not finding the 3w_9xxx driver, but I don't need to load that in the initrd anyway so I reran with --builtin=3w_9xxx so that mkinitrd would skip that driver that I don't need. BUT, after all of this, I get a bunch of errors when I try to run lilo: Fatal: Trying to map files from unnamed device 0x 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: Making bootable SATA RAID1 array in Mandriva 2006
On Mon, Aug 14, 2006 at 06:50:30AM -0400, andy liebman wrote: -- I edited fstab and lilo.conf on the the RAID1 / partition so that they would refer to /dev/md1 -- I ran chroot on the /dev/md1 partition did you mount /dev, /proc and /sys before chrooting? i.e mount --bind /dev /newroot/dev mount -t proc /proc /newroot/proc mount -t sysfs /sys /newroot/sys Why do I have to do this? I haven't seen this in any recipies. My you need it because mkinitrd will need info from /proc and /sys to work correctly and lilo will try to access /proc/partitions and /dev/md1 if your /boot is on /dev/md1. Linux setup only has three partitions: /, swap, and /home. /dev /proc and /sys are not disk based filesystems /dev is a ram disk which is populated at runtime by udev /proc and /sys are virtual filesystem that expose some of your hw and kernel configuration to userspace I'm not sure I understand what you're saying about mounting /dev, /proc and /sys. just run: mount --bind /dev /newroot/dev mount -t proc /proc /newroot/proc mount -t sysfs /sys /newroot/sys before chrooting L. btw, be sure to add auto=yes to the ARRAY lines in /etc/mdadm.conf or you might find some arrays are not recognized after boot. 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: Making bootable SATA RAID1 array in Mandriva 2006
On Mon, Aug 14, 2006 at 05:13:47PM +0200, Laurent Lesage wrote: Hi Andy, there are options for the mkinitrd command, that are like the parameters in mkinitrd.conf (this is the case in Debian). did you use the -root=xxx option? Laurent, mkinitrd in debian and mandriva are two completely different beasts, there is no relation between those two. besides that, i believe that all Andy has to do for mkinitrd is mounting /sys on the chroot before running mkinitrd. there is no mkinitrd.conf on mandriva. mkinitrd will use fstab to find the root filesystem, so the change Andy did is correct. and please, please, stop top-posting and try to quote relevant parts of messages when answering, or the thread will become unreadable. 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: Imaging Mirrored OS Drives
On Wed, Aug 16, 2006 at 01:05:39PM -0400, andy liebman wrote: if the imaging software is not too smart and creates the partitions and filesystems with the exact same size as the original, yes. (i mean that there should be some space between the end of the filesystem and the end of the partition to store the md superblock) 2) Furthermore, if the above is possible, in creating the arrays on the new drives is there a way to force mdadm to give the arrays specific UUID numbers? It looks like I can do that with mdadm --update? Should I create the arrays first using the normal mdadm -C procedure, and then update the UUIDs? never tried that, let us know how you fare. 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: Can you IMAGE Mirrored OS Drives?
On Sat, Aug 19, 2006 at 03:13:53AM +0200, Gabor Gombas wrote: but you would have to regenerate the initrd and fight again with lilo :( Or you can just build a kernel with md built-in and use the kernel-level RAID autodetection. In situations like this it is _much_ easier and _much_ more robust than all the initrd-based solutions I have seen. please, can we try not to resurrect again the kernel-level autodetection flamewar on this list. 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: checking md device parity (forced resync) - is it necessary?
On Tue, Sep 05, 2006 at 02:00:03PM +0200, Tomasz Chmielewski wrote: # by default, run at 01:06 on the first Sunday of each month. 6 1 1-7 * 7 root [ -x /usr/share/mdadm/checkarray ] /usr/share/mdadm/checkarray --cron --all --quiet However, it will run at 01:06, on 1st-7th day of each month, and on Sundays (Debian etch). hihihi monthday and weekday are or-ed in crontab 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: Care and feeding of RAID?
On Tue, Sep 05, 2006 at 02:29:48PM -0400, Steve Cousins wrote: Benjamin Schieder wrote: On 05.09.2006 11:03:45, Steve Cousins wrote: Would people be willing to list their setup? Including such things as mdadm.conf file, crontab -l, plus scripts that they use to check the smart data and the array, mdadm daemon parameters and anything else that is relevant to checking and maintaining an array? Personally, I use this script from cron: http://shellscripts.org/project/hdtest nice race :) I am checking this out and I see that you are the writer of this script. I'm getting errors when it comes to lines 76 and 86-90 about the arithmetic symbols. This is on a Fedora Core 5 system with bash version that is because smartctl output has changed and the grep above returns no number. 3.1.7(1). I weeded out the smartctl command and tried it manually with no luck on my SATA /dev/sd? drives. which command? What do you (or others) recommend for SATA drives? smartmontools and a recent kernel just work. also you can schedule smart tests with smartmontools. so you don't need to cron scripts. 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: Care and feeding of RAID?
On Tue, Sep 05, 2006 at 05:47:57PM -0400, Steve Cousins wrote:
Luca Berra wrote:
On Tue, Sep 05, 2006 at 02:29:48PM -0400, Steve Cousins wrote:
Benjamin Schieder wrote:
On 05.09.2006 11:03:45, Steve Cousins wrote:
Would people be willing to list their setup? Including such things
as mdadm.conf file, crontab -l, plus scripts that they use to check
the smart data and the array, mdadm daemon parameters and anything
else that is relevant to checking and maintaining an array?
Personally, I use this script from cron:
http://shellscripts.org/project/hdtest
nice race :)
I'm not sure what you mean?
tmp=`mktemp`
rm -f ${tmp}
touch ${tmp}
the last two lines are unneeded and can be tricked to overwrite
arbitrary filenames
I tried smartctl -t short -d scsi /dev/sdb where /dev/sdb is a 250GB
SATA drive.
it is '-d ata'
What command do you use for SATA drives? The sourceforge page implies
that -d sata doesn't exist yet. I'm using FC 5 with 2.6.17 kernel and
smartmontools version 5.33. Do you have a sample configuration script
that you could show me?
# monitor two sata disks, show temperature in degrees,
# do a long test every sunday and a short every other day
# at 1am on sda and at 2am on sdb, YMMV
/dev/sda -d ata -a -R 194 -s (L/../../7|S/../../[123456])/01
/dev/sdb -d ata -a -R 194 -s (L/../../7|S/../../[123456])/02
--
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: Care and feeding of RAID?
On Wed, Sep 06, 2006 at 09:12:24AM +0200, Benjamin Schieder wrote:
Personally, I use this script from cron:
http://shellscripts.org/project/hdtest
nice race :)
As in race condition? Where?
mktemp
rm
touch
why do you do that?
I'm running smartmontools 5.33 here. When did the output change? It still
works fine here.
i retested now with 5.36 and it seems the output did _not_ change, i
don't know what i saw this morning.
but then it errors on the line
IFS=read type status online ( smartctl -d ata -a ${disk} | grep
\#\ 1 | sed 's, \+, ,g' | cut -f 2,3,5 )
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: RAID5 fill up?
On Fri, Sep 08, 2006 at 02:26:31PM +0200, Lars Schimmer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Tokarev wrote: Lars Schimmer wrote: Hi! I´ve got a software RAiD5 with 6 250GB HDs. Now I changed one disk after another to a 400GB HD and resynced the raid5 after each change. Now the RAID5 has got 6 400GB HDs and still uses only 6*250GB space. How can I grow the md0 device to use 6*400GB? mdadm --grow is your friend. Oh, damn, right. I was focussed on --grow to add a new HD to the RAID But isn´t there a switch to grow to max possible value? Do I always have to search for the biggest value and type it in by hand? man mdadm -z, --size= This value can be set with --grow for RAID level 1/4/5/6. If the array was created with a size smaller than the currently active drives, the extra space can be accessed using --grow. The size can be given as max which means to choose the largest size that fits on all current drives. -- 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
[PATCH] missing close in mdassemble
attached, please apply without this mdassemble cannot activate stacked arrays, i wonder how i managed to miss it :( L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ --- mdadm-2.5.3/mdassemble.c.close 2006-09-13 12:28:00.0 +0200 +++ mdadm-2.5.3/mdassemble.c2006-09-13 12:30:24.0 +0200 @@ -91,13 +91,12 @@ rv |= 1; continue; } - if (ioctl(mdfd, GET_ARRAY_INFO, array)=0) - /* already assembled, skip */ - continue; + if (ioctl(mdfd, GET_ARRAY_INFO, array) 0) rv |= Assemble(array_list-st, array_list-devname, mdfd, array_list, NULL, NULL, readonly, runstop, NULL, NULL, verbose, force); + close(mdfd); } return rv; }
Re: [PATCH] missing close in mdassemble
On Wed, Sep 13, 2006 at 04:57:43PM +0200, Luca Berra wrote:
attached, please apply
without this mdassemble cannot activate stacked arrays, i wonder how i
managed to miss it :(
Another patch which obsoletes the previous one
this will make mdassemble, if run a second time, try to make
arrays read-write. Useful if one starts arrays readonly as described in
README.initramfs, after resume fails.
L.
--
Luca Berra -- [EMAIL PROTECTED]
Communication Media Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
XAGAINST HTML MAIL
/ \
--- mdadm-2.5.3/mdassemble.c.close 2006-06-26 07:11:00.0 +0200
+++ mdadm-2.5.3/mdassemble.c2006-09-13 17:23:15.0 +0200
@@ -91,13 +91,14 @@
rv |= 1;
continue;
}
- if (ioctl(mdfd, GET_ARRAY_INFO, array)=0)
- /* already assembled, skip */
- continue;
- rv |= Assemble(array_list-st, array_list-devname,
mdfd,
- array_list,
- NULL, NULL,
+ if (ioctl(mdfd, GET_ARRAY_INFO, array) 0) {
+ rv |= Assemble(array_list-st,
array_list-devname, mdfd,
+ array_list, NULL, NULL,
readonly, runstop, NULL, NULL,
verbose, force);
+ } else {
+ rv |= Manage_ro(array_list-devname, mdfd, -1);
/* make it readwrite */
+ }
+ close(mdfd);
}
return rv;
}
--- mdadm-2.5.3/Makefile.close 2006-06-20 02:01:17.0 +0200
+++ mdadm-2.5.3/Makefile2006-09-13 17:54:36.0 +0200
@@ -76,7 +76,7 @@
STATICSRC = pwgr.c
STATICOBJS = pwgr.o
-ASSEMBLE_SRCS := mdassemble.c Assemble.c config.c dlink.c util.c super0.c
super1.c sha1.c
+ASSEMBLE_SRCS := mdassemble.c Assemble.c Manage.c config.c dlink.c util.c
super0.c super1.c sha1.c
ASSEMBLE_FLAGS:= $(CFLAGS) -DMDASSEMBLE
ifdef MDASSEMBLE_AUTO
ASSEMBLE_SRCS += mdopen.c mdstat.c
--- mdadm-2.5.3/Manage.c.close 2006-06-26 04:26:07.0 +0200
+++ mdadm-2.5.3/Manage.c2006-09-13 17:25:31.0 +0200
@@ -72,6 +72,8 @@
return 0;
}
+#ifndef MDASSEMBLE
+
int Manage_runstop(char *devname, int fd, int runstop, int quiet)
{
/* Run or stop the array. array must already be configured
@@ -393,3 +395,5 @@
return 0;
}
+
+#endif /* MDASSEMBLE */
--- mdadm-2.5.3/util.c.close2006-09-13 17:29:19.0 +0200
+++ mdadm-2.5.3/util.c 2006-09-13 18:08:56.0 +0200
@@ -189,6 +189,7 @@
}
}
+#ifndef MDASSEMBLE
int check_ext2(int fd, char *name)
{
/*
@@ -286,6 +287,7 @@
fprintf(stderr, Name : assuming 'no'\n);
return 0;
}
+#endif /* MDASSEMBLE */
char *map_num(mapping_t *map, int num)
{
@@ -307,7 +309,6 @@
return UnSet;
}
-
int is_standard(char *dev, int *nump)
{
/* tests if dev is a standard md dev name.
@@ -482,6 +483,7 @@
return csum;
}
+#ifndef MDASSEMBLE
char *human_size(long long bytes)
{
static char buf[30];
@@ -534,7 +536,9 @@
);
return buf;
}
+#endif /* MDASSEMBLE */
+#if !defined(MDASSEMBLE) || defined(MDASSEMBLE) defined(MDASSEMBLE_AUTO)
int get_mdp_major(void)
{
static int mdp_major = -1;
@@ -618,6 +622,7 @@
if (strncmp(name, /dev/.tmp.md, 12)==0)
unlink(name);
}
+#endif /* !defined(MDASSEMBLE) || defined(MDASSEMBLE)
defined(MDASSEMBLE_AUTO) */
int dev_open(char *dev, int flags)
{
--- mdadm-2.5.3/mdassemble.8.close 2006-08-07 03:33:56.0 +0200
+++ mdadm-2.5.3/mdassemble.82006-09-13 18:25:41.0 +0200
@@ -25,6 +25,13 @@
.B mdassemble
has the same effect as invoking
.B mdadm --assemble --scan.
+.PP
+Invoking
+.B mdassemble
+a second time will make all defined arrays readwrite, this is useful if
+using the
+.B start_ro
+module parameter.
.SH OPTIONS
@@ -54,6 +61,5 @@
.PP
.BR mdadm (8),
.BR mdadm.conf (5),
-.BR md (4).
-.PP
+.BR md (4),
.BR diet (1).
Re: RAID5 producing fake partition table on single drive
On Fri, Sep 15, 2006 at 05:51:12PM +1000, Lem wrote: On Thu, 2006-09-14 at 18:42 -0400, Bill Davidsen wrote: Lem wrote: On Mon, 2006-09-04 at 13:55 -0400, Bill Davidsen wrote: May I belatedly say that this is sort-of a kernel issue, since /proc/partitions reflects invalid data? Perhaps a boot option like nopart=sda,sdb or similar would be in order? My suggestion was to Neil or other kernel maintainers. If they agree that this is worth fixing, the option could be added in the kernel. It isn't there now, I was soliciting responses on whether this was desirable. My mistake, sorry. It sounds like a nice idea, and would work well in cases where the RAID devices are always assigned the same device names (sda, sdb, sdc etc), which I'd expect to be the case quite frequently. that is the issue, quite frequently != always Unfortunately I see no way to avoid data in the partition table location, which looks like a partition table, from being used. Perhaps an alternative would be to convert an array with non-partition-based devices to partition-based devices, though I remember Neil saying this would involve relocating all of the data on the entire array (perhaps could be done through some funky resync option?). sorry, i do not agree ms-dos partitions are a bad idea, and one i would really love to leave behind. what i'd do is move the partition detect code to userspace where it belongs, togheter with lvm, md, dmraid, multipath and evms so what userspace would do is: check if any wholedisk is one of the above mentioned types or if it is partitionable. I believe the order would be something like: dmraid or multipath evms (*) md lvm partition table (partx or kpartx) md lvm (*) evms should handle all cases by itself after each check the device list for the next check should be recalculated removing devices handled and adding new devices just created. this is too much to be done in kernel space, but it can be done easily in initramfs or initscript. just say Y to CONFIG_PARTITION_ADVANCED and N to all other CONFIG_?_PARTITION and code something in userspace. L. P.S. the op can simply use partx to remove partition tables from the components of the md array just after assembling. 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: ANNOUNCE: mdadm 2.5.4 - A tool for managing Soft RAID under Linux
On Fri, Oct 13, 2006 at 10:15:35AM +1000, Neil Brown wrote:
I am pleased to announce the availability of
mdadm version 2.5.4
it looks like you did not include the patches i posted against 2.5.3
--
Luca Berra -- [EMAIL PROTECTED]
Communication Media Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
XAGAINST HTML MAIL
/ \
* Sat Aug 19 2006 Luca Berra [EMAIL PROTECTED]
- do not fail when autoassembling everything and some md are already active
--- mdadm-2.5.3/mdadm.c 2006-08-19 17:00:51.0 +0200
+++ mdadm-2.5.3/mdadm.c 2006-08-19 16:30:16.0 +0200
@@ -1020,7 +1020,7 @@
}
if (ioctl(mdfd, GET_ARRAY_INFO, array)=0)
/* already assembled, skip */
- ;
+ cnt++;
else {
rv |= Assemble(ss, array_list-devname,
mdfd,
array_list,
--- mdadm-2.5.3/mdopen.c2006-06-26 07:11:00.0 +0200
+++ mdadm-2.5.3/mdopen.c2006-08-19 17:03:24.0 +0200
@@ -166,10 +166,7 @@
}
if (ioctl(mdfd, GET_ARRAY_INFO, array)==0) {
/* already active */
- close(mdfd);
- fprintf(stderr, Name : %s is already
active.\n,
- dev);
- return -1;
+ return mdfd;
} else {
if (major != MD_MAJOR parts 0)
make_parts(dev, parts);
--- mdadm-2.5.3/mdassemble.c.close 2006-06-26 07:11:00.0 +0200
+++ mdadm-2.5.3/mdassemble.c2006-09-13 17:23:15.0 +0200
@@ -91,13 +91,14 @@
rv |= 1;
continue;
}
- if (ioctl(mdfd, GET_ARRAY_INFO, array)=0)
- /* already assembled, skip */
- continue;
- rv |= Assemble(array_list-st, array_list-devname,
mdfd,
- array_list,
- NULL, NULL,
+ if (ioctl(mdfd, GET_ARRAY_INFO, array) 0) {
+ rv |= Assemble(array_list-st,
array_list-devname, mdfd,
+ array_list, NULL, NULL,
readonly, runstop, NULL, NULL,
verbose, force);
+ } else {
+ rv |= Manage_ro(array_list-devname, mdfd, -1);
/* make it readwrite */
+ }
+ close(mdfd);
}
return rv;
}
--- mdadm-2.5.3/Makefile.close 2006-06-20 02:01:17.0 +0200
+++ mdadm-2.5.3/Makefile2006-09-13 17:54:36.0 +0200
@@ -76,7 +76,7 @@
STATICSRC = pwgr.c
STATICOBJS = pwgr.o
-ASSEMBLE_SRCS := mdassemble.c Assemble.c config.c dlink.c util.c super0.c
super1.c sha1.c
+ASSEMBLE_SRCS := mdassemble.c Assemble.c Manage.c config.c dlink.c util.c
super0.c super1.c sha1.c
ASSEMBLE_FLAGS:= $(CFLAGS) -DMDASSEMBLE
ifdef MDASSEMBLE_AUTO
ASSEMBLE_SRCS += mdopen.c mdstat.c
--- mdadm-2.5.3/Manage.c.close 2006-06-26 04:26:07.0 +0200
+++ mdadm-2.5.3/Manage.c2006-09-13 17:25:31.0 +0200
@@ -72,6 +72,8 @@
return 0;
}
+#ifndef MDASSEMBLE
+
int Manage_runstop(char *devname, int fd, int runstop, int quiet)
{
/* Run or stop the array. array must already be configured
@@ -393,3 +395,5 @@
return 0;
}
+
+#endif /* MDASSEMBLE */
--- mdadm-2.5.3/util.c.close2006-09-13 17:29:19.0 +0200
+++ mdadm-2.5.3/util.c 2006-09-13 18:08:56.0 +0200
@@ -189,6 +189,7 @@
}
}
+#ifndef MDASSEMBLE
int check_ext2(int fd, char *name)
{
/*
@@ -286,6 +287,7 @@
fprintf(stderr, Name : assuming 'no'\n);
return 0;
}
+#endif /* MDASSEMBLE */
char *map_num(mapping_t *map, int num)
{
@@ -307,7 +309,6 @@
return UnSet;
}
-
int is_standard(char *dev, int *nump)
{
/* tests if dev is a standard md dev name.
@@ -482,6 +483,7 @@
return csum;
}
+#ifndef MDASSEMBLE
char *human_size(long long bytes)
{
static char buf[30];
@@ -534,7 +536,9 @@
);
return buf;
}
+#endif /* MDASSEMBLE */
+#if !defined(MDASSEMBLE) || defined(MDASSEMBLE) defined(MDASSEMBLE_AUTO)
int get_mdp_major(void)
{
static int mdp_major = -1;
@@ -618,6 +622,7 @@
if (strncmp(name, /dev/.tmp.md, 12)==0)
unlink(name);
}
+#endif /* !defined(MDASSEMBLE) || defined(MDASSEMBLE)
defined(MDASSEMBLE_AUTO
Re: problem during boot with linux software raid 5
On Fri, Oct 13, 2006 at 06:28:21PM -0400, jeff wrote:
I am running mandrake 2006 linux.
s/mandrake/mandriva
uname -a reports
Linux dual_933 2.6.12-12mdksmp #1 SMP Fri Sep 9 17:43:23 CEST 2005 i686
Pentium III (Coppermine) unknown GNU/Linux
not strictly related to your problem, but you should really consider
applying updates from your distribution.
snip
When I rebooted, the reboot hung. I think for some reason it didn't
automatically start the md0 device, and as a result it couldn't mount
the /dev/md0 partition in my /etc/fstab. I went into single-user mode,
and commented out the /dev/md0 line in /etc/fsab, and I was able to
boot. Then I executed the mdadm --create line, uncommented /etc/fstab,
and I was able to access my data.
the command to activate an already existing raid set is mdadm
--assemble, not mdadm --create
I was reading some documentation, and it said that you can use mdadm on
either partitions or on a device (as I did). When you have partitions, I
read that you should set the partition type to 0xFD so they get
autodetected during boot. I can't do this, as I don't have partitions.
this is junk documentation do not believe in it :=)
mandriva boot process uses mdadm to assemble raid devices at boot time
but you need to tell mdadm which arrays it should find at boot by
editing /etc/mdadm.conf, just run the following code snippet:
#!/bin/sh
grep -qs '/^[[:space:]]*DEVICE' /etc/mdadm.conf || \
echo DEVICE partitions /etc/mdadm.conf
mdadm -Esc partitions | awk '
/^ARRAY[[:space:]]/ {
print $0, auto=yes
}
' /etc/mdadm.conf
--
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: md device on Redhat Linux 3
On Wed, Jan 31, 2007 at 11:52:17AM +1100, Neil Brown wrote: On Tuesday January 30, [EMAIL PROTECTED] wrote: Hi there, I am currenlty building a site ysing the following 2 * IBM DS4300 (SANS) 2 * IBM X346 (intel systems) 2 * HBA on each node I am using the md device driver to tie the two SANS together and use them in a mirrored environement. So the layout is 3 file systems sitting under and LVM volume group siting under a mirrored SAN (/dev/sdb, /dev/sdc) on 2 g.b. fibre using md driver. The problem when we write to one of the SANS when he mirror is broken and then take this offline and ring the other SAN online and switch on the RAID array and varyon the volume group and finally mount the file system and then dismount the file system,swithc of both the volume group and the RAID array and thn reboot the server it finds the most recently updated disk to be the one written to not the one last mounted. It's not really clear to me what you are trying to do here maybe if you explain your motivations and expectations. Usually if you get in the unpleasant situation of having two different versions of your data you _must_ ensure that automatic resyncronization does not happen at all. (you might need to manually copy data from one storage to the other) maybe mdadm could help, by having some options to control startup of degraded or unclean arrays. At the moment the best opion is to have a script that checks availability of device nodes before starting the array, and refuses to start if the array would be degraded. In case you need to force a copy to start you can use mdadm --create with the missing option to forcibly kick the other storage from the array. Also a nice add-on to mdadm would be a command to increase the event counter of the remaining devices on a degraded array, to ensure those will be considered to be uptodate at next restart. 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: trouble creating array
On Mon, Feb 26, 2007 at 03:40:32AM -0800, jahammonds prost wrote: Ah ha # ls -l /sys/block/*/holders/* lrwxrwxrwx 1 root root 0 Feb 26 06:28 /sys/block/sdb/holders/dm-0 - ../../../block/dm-0 lrwxrwxrwx 1 root root 0 Feb 26 06:28 /sys/block/sdc/holders/dm-0 - ../../../block/dm-0 which I am assuming is dmraid? I did a quick check, and no, it is device-mapper # dmraid -r No RAID disks use dmsetup ls 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: s2disk and raid
On Wed, Apr 04, 2007 at 03:20:56PM +1000, Neil Brown wrote: The trick is to use the 'start_ro' module parameter. echo 1 /sys/module/md_mod/parameters/start_ro Then md will start arrays assuming read-only. No resync will be started, no superblock will be written. They stay this way until the first write at which point they become normal read-write and any required resync starts. uh, i tought a read-only array was supposed to remain read-only, and that write attempts would fail. My bad for not testing my assumptions. 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: raid1 resync data direction defined?
On Fri, Jul 27, 2007 at 03:07:13PM +0200, Frank van Maarseveen wrote: I'm experimenting with a live migration of /dev/sda1 using mdadm -B and network block device as in: mdadm -B -ayes -n2 -l1 /dev/md1 /dev/sda1 \ --write-mostly -b /tmp/bitm$$ --write-behind /dev/nbd1 not a good idea /dev/sda1 is to be migrated. During the migration the local system mounts from /dev/md1 instead. Stracing shows that data flows to the remote side. But when I do echo repair /sys/block/md1/md/sync_action then the data flows in the other direction: the local disk is written using data read from the remote side. I believe stracing nbd will give you a partial view of what happens. anyway in the first case since the second device is write-mostly, all data is read from local and changes are written to remote In the second one the data is read from both sides to be compared, that is what you are seing on strace, i am unsure as to which copy is considered correct, since md does not have info about that. If that would happen in the first command then it would destroy all yes data instead of migrating it so I wonder if this behavior is defined: no Do mdadm --build and mdadm --create always use the first component device on the command-line as the source for raid1 resync? no if you are doing a migration, build the initial array with the second device as missing then hot-add it and it will resync correctly i.e mdadm -B -ayes -n2 -l1 /dev/md1 /dev/sda1 \ --write-mostly -b /tmp/bitm$$ --write-behind missing mdadm -a /dev/md1 /dev/sda1 -- 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: MD RAID1 performance very different from non-RAID partition
On Mon, Sep 17, 2007 at 10:58:11AM -0500, Jordan Russell wrote: Goswin von Brederlow wrote: Jordan Russell [EMAIL PROTECTED] writes: It's an ext3 partition, so I guess that doesn't apply? I tried remounting /dev/sda2 with the barrier=0 option (which I assume disables barriers, looking at the source), though, just to see if it would make any difference, but it didn't; the database build still took 31 minutes. Compare the read ahead settings. I'm not sure what you mean. There's a per-mount read ahead setting? per device compare blockdev --getra /dev/sda2 and blockdev --getra /dev/md0 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: Raid-10 mount at startup always has problem
On Thu, Oct 25, 2007 at 02:40:06AM -0400, Doug Ledford wrote: partition table (something that the Fedora/RHEL installers do to all disks without partition tables...well, the installer tells you there's no partition table and asks if you want to initialize it, but if someone is in a hurry and hits yes when they meant no, bye bye data). Cool feature The partition table is the single, (mostly) universally recognized arbiter of what possible data might be on the disk. Having a partition table may not make mdadm recognize the md superblock any better, but it keeps all that other stuff from even trying to access data that it doesn't have a need to access and prevents random luck from turning your day bad. on a pc maybe, but that is 20 years old design. partition table design is limited because it is still based on C/H/S, which do not exist anymore. Put a partition table on a big storage, say a DMX, and enjoy a 20% performance decrease. Oh, and let's not go into what can happen if you're talking about a dual boot machine and what Windows might do to the disk if it doesn't think the disk space is already spoken for by a linux partition. Why the hell should the existance of windows limit the possibility of linux working properly. If i have a pc that dualboots windows i will take care of using the common denominator of a partition table, if it is my big server i will probably not. since it won't boot anything else than Linux. And, in particular with mdadm, I once created a full disk md raid array on a couple disks, then couldn't get things arranged like I wanted, so I just partitioned the disks and then created new arrays in the partitions (without first manually zeroing the superblock for the whole disk array). Since I used a version 1.0 superblock on the whole disk array, and then used version 1.1 superblocks in the partitions, the net result was that when I ran mdadm -Eb, mdadm would find both the 1.1 and 1.0 superblocks in the last partition on the disk. Confused both myself and mdadm for a while. yes, this is fun On the opposite, i once inserted an mmc memory card, which had been initialized on my mobile phone, into the mmc slot of my laptop, and was faced with a load of error about mmcblk0 having an invalid partition table. Obviously it had none, it was a plain fat filesystem. Is the solution partitioning it? I don't think the phone would agree. Anyway, I happen to *like* the idea of using full disk devices, but the reality is that the md subsystem doesn't have exclusive ownership of the disks at all times, and without that it really needs to stake a claim on the space instead of leaving things to chance IMO. Start removing the partition detection code from the blasted kernel and move it to userspace, which is already in place, but it is not the default. -- 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
