proactive-raid-disk-replacement
Recently Dean Gaudet, in thread titled 'Feature Request/Suggestion - Drive Linking', mentioned his document, http://arctic.org/~dean/proactive-raid5-disk-replacement.txt I've read it, and have some umm.. concerns. Here's why: mdadm -Gb internal --bitmap-chunk=1024 /dev/md4 mdadm /dev/md4 -r /dev/sdh1 mdadm /dev/md4 -f /dev/sde1 -r /dev/sde1 mdadm --build /dev/md5 -ayes --level=1 --raid-devices=2 /dev/sde1 missing mdadm /dev/md4 --re-add /dev/md5 mdadm /dev/md5 -a /dev/sdh1 ... wait a few hours for md5 resync... And here's the problem. While new disk, sdh1, are resynced from old, probably failing disk sde1, chances are high that there will be an unreadable block on sde1. And this means the whole thing will not work -- md5 initially contained one working drive (sde1) and one spare (sdh1) which is being converted (resynced) to working disk. But after read error on sde1, md5 will contain one failed drive and one spare -- for raid1 it's fatal combination. While at the same time, it's perfectly easy to reconstruct this failing block from other component devices of md4. That to say: this way of replacing disk in a software raid array isn't much better than just removing old drive and adding new one. And if the drive you're replacing is failing (according to SMART for example), this method is more likely to fail. /mjt - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proactive-raid-disk-replacement
On Fri, 8 Sep 2006, Michael Tokarev wrote: Recently Dean Gaudet, in thread titled 'Feature Request/Suggestion - Drive Linking', mentioned his document, http://arctic.org/~dean/proactive-raid5-disk-replacement.txt I've read it, and have some umm.. concerns. Here's why: mdadm -Gb internal --bitmap-chunk=1024 /dev/md4 mdadm /dev/md4 -r /dev/sdh1 mdadm /dev/md4 -f /dev/sde1 -r /dev/sde1 mdadm --build /dev/md5 -ayes --level=1 --raid-devices=2 /dev/sde1 missing mdadm /dev/md4 --re-add /dev/md5 mdadm /dev/md5 -a /dev/sdh1 ... wait a few hours for md5 resync... And here's the problem. While new disk, sdh1, are resynced from old, probably failing disk sde1, chances are high that there will be an unreadable block on sde1. And this means the whole thing will not work -- md5 initially contained one working drive (sde1) and one spare (sdh1) which is being converted (resynced) to working disk. But after read error on sde1, md5 will contain one failed drive and one spare -- for raid1 it's fatal combination. While at the same time, it's perfectly easy to reconstruct this failing block from other component devices of md4. this statement is an argument for native support for this type of activity in md itself. That to say: this way of replacing disk in a software raid array isn't much better than just removing old drive and adding new one. hmm... i'm not sure i agree. in your proposal you're guaranteed to have no redundancy while you wait for the new disk to sync in the raid5. in my proposal the probability that you'll retain redundancy through the entire process is non-zero. we can debate how non-zero it is, but non-zero is greater than zero. i'll admit it depends a heck of a lot on how long you wait to replace your disks, but i prefer to replace mine well before they get to the point where just reading the entire disk is guaranteed to result in problems. And if the drive you're replacing is failing (according to SMART for example), this method is more likely to fail. my practice is to run regular SMART long self tests, which tend to find Current_Pending_Sectors (which are generally read errors waiting to happen) and then launch a repair sync action... that generally drops the Current_Pending_Sector back to zero. either through a realloc or just simply rewriting the block. if it's a realloc then i consider if there's enough of them to warrant replacing the disk... so for me the chances of a read error while doing the raid1 thing aren't as high as they could be... but yeah you've convinced me this solution isn't good enough. -dean - 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 RAID checking observations - I'm getting it too
Hi Bill, On Mon, 04 Sep 2006 12:42:53 -0400 Bill Davidsen [EMAIL PROTECTED] wrote: Mark Smith wrote: Interesting, but do you run other stuff at that time? Several distributions run various things in the middle of the night which really bog the machine. Doesn't look like it. Shifted the check to 3.00am, 4.00am period is now all nothing : 00:01:01 CPU %user %nice %system %iowait%steal %idle . . 03:56:02 all 0.85 0.00 0.38 0.00 0.00 98.77 04:01:01 all 0.75 0.00 0.34 0.00 0.00 98.91 04:06:01 all 0.73 0.00 0.35 0.00 0.00 98.92 04:11:01 all 0.73 0.00 0.38 0.00 0.00 98.89 04:16:01 all 0.84 0.00 0.37 0.00 0.00 98.79 04:21:01 all 0.68 0.00 0.34 0.00 0.00 98.98 04:26:01 all 0.78 0.00 0.39 0.00 0.00 98.83 04:31:01 all 1.18 0.00 0.40 0.00 0.00 98.43 04:36:01 all 0.88 0.00 0.33 0.00 0.00 98.79 04:41:01 all 0.72 0.00 0.38 0.00 0.00 98.90 04:46:01 all 0.80 0.00 0.42 0.00 0.00 98.78 . . Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear - 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
RAID5 fill up?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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? MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: [EMAIL PROTECTED] Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAThzmWhuE0qbFyMRApImAJ9j3CJRyfoGeg2IthY6JCMDRs5GugCfQZIY ENAC2gqh3fc8/HZQs1dUhAs= =guH4 -END PGP SIGNATURE- - 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
RAID5 fill up?
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? MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: [EMAIL PROTECTED] Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 - 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?
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. /mjt - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proactive-raid-disk-replacement
dean gaudet wrote: On Fri, 8 Sep 2006, Michael Tokarev wrote: Recently Dean Gaudet, in thread titled 'Feature Request/Suggestion - Drive Linking', mentioned his document, http://arctic.org/~dean/proactive-raid5-disk-replacement.txt I've read it, and have some umm.. concerns. Here's why: mdadm -Gb internal --bitmap-chunk=1024 /dev/md4 By the way, don't specify bitmap-chunk for internal bitmap. It's needed for file-based (external) bitmap. With internal bitmap, we have fixed size in superblock for it, so bitmap-chunk is determined by dividing that size by size of the array. mdadm /dev/md4 -r /dev/sdh1 mdadm /dev/md4 -f /dev/sde1 -r /dev/sde1 mdadm --build /dev/md5 -ayes --level=1 --raid-devices=2 /dev/sde1 missing mdadm /dev/md4 --re-add /dev/md5 mdadm /dev/md5 -a /dev/sdh1 ... wait a few hours for md5 resync... And here's the problem. While new disk, sdh1, are resynced from old, probably failing disk sde1, chances are high that there will be an unreadable block on sde1. And this means the whole thing will not work -- md5 initially contained one working drive (sde1) and one spare (sdh1) which is being converted (resynced) to working disk. But after read error on sde1, md5 will contain one failed drive and one spare -- for raid1 it's fatal combination. While at the same time, it's perfectly easy to reconstruct this failing block from other component devices of md4. this statement is an argument for native support for this type of activity in md itself. Yes, definitely. That to say: this way of replacing disk in a software raid array isn't much better than just removing old drive and adding new one. hmm... i'm not sure i agree. in your proposal you're guaranteed to have no redundancy while you wait for the new disk to sync in the raid5. It's not a proposal per se, it's just another possible way (used by majority of users I think, because it's way simpler ;) in my proposal the probability that you'll retain redundancy through the entire process is non-zero. we can debate how non-zero it is, but non-zero is greater than zero. Yes there will be no redundancy in my variant, guaranteed. And yes, there is probability to complete the whole your process without a glitch. i'll admit it depends a heck of a lot on how long you wait to replace your disks, but i prefer to replace mine well before they get to the point where just reading the entire disk is guaranteed to result in problems. And if the drive you're replacing is failing (according to SMART for example), this method is more likely to fail. my practice is to run regular SMART long self tests, which tend to find Current_Pending_Sectors (which are generally read errors waiting to happen) and then launch a repair sync action... that generally drops the Current_Pending_Sector back to zero. either through a realloc or just simply rewriting the block. if it's a realloc then i consider if there's enough of them to warrant replacing the disk... so for me the chances of a read error while doing the raid1 thing aren't as high as they could be... So the whole thing goes this way: 0) do a SMART selftest ;) 1) do repair for the whole array 2) copy data from failing to new drive (using temporary superblock-less array) 2a) if step 2 failed still, probably due to new bad sectors, go the old way, removing the failing drive and adding new one. That's 2x or 3x (or 4x counting the selftest, but that should be done regardless) more work than just going the old way from the beginning, but still some chances to have it completed flawlessly in 2 steps, without losing redundancy. Too complicated and too long for most people I'd say ;) I can come to yet another way, which is only somewhat possible with current md code. In 3 variants. 1) Offline the array, stop it. Make a copy of the drive using dd with error=skip (or how it is), noticing the bad blocks Mark those bad blocks in bitmap as dirty Assemble the array with new drive, letting it to resync the blocks to new drive which we were unable to copy previously. This variant does not lose redundancy at all, but requires the array to be off-line during the whole copy procedure. What's missing (which has been discussed on linux-raid@ recently too) is the ability to mark those bad blocks in bitmap. 2) The same, but not offlining the array. Hot-remove a drive, make copy of it to new drive, flip necessary bitmap bits, and re-add the new drive, and let raid code to resync changed (during copy, while the array was still active, something might has changed) and missing blocks. This variant still loses redundancy, but not much of it, provided the bitmap code works correctly. 3) The same as your way, with the difference that we tell md to *skip* and ignore possible errors during resync (which is also not possible currently). but yeah you've convinced me this solution isn't good
Re: RAID5 fill up?
-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? /mjt MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: [EMAIL PROTECTED] Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAWF3mWhuE0qbFyMRAn7QAJ9nZ7I+n/bxM22AoKbfSXoMovup8ACfS+i6 nYASA51BlYQaSavD7CWLL8c= =S0dO -END PGP SIGNATURE- - 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
Re: RAID5 fill up?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Tokarev wrote: Lars Schimmer wrote: [] 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? How about actually reading the fine manual? ;-P -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. *damn* This must be the friday... Or I´m in weekend to fast. THANKS so far. /mjt MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: [EMAIL PROTECTED] Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAXMUmWhuE0qbFyMRAtqjAJ96irdwtHjIEpvXbrq60a01VLAsMQCdHhCn YIPwr2pZQ7cErVc9NxenxGA= =Kgy0 -END PGP SIGNATURE- - 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
Messed up creating new array...
Folks,
I messed up slightly when creating a new 6-disk raid6 array, and am wondering
if there is a simple answer. The problem is that I didn't partition the drives,
but simply used the whole drive. All drives are of the same type and using the
Supermicro SAT2-MV8 controller.
This is a problem because mdadm doesn't find the component drives... I can only
start the array by using mdadm --assemble /dev/md3 /dev/sd{drives}. While
this works it means my system doesn't boot very easily :-(
For fixes I can think of the possible solutions:
- Modify the startup script to do the mdadm --assemble /dev/md3
/dev/sd{a,b,c,d,e}. Is there any other disadvantage of this?
- Use fdisk to create whole-disk partitions - but would this damage the
already stored data?
- Start again doing it right But this will take 12 hours and has a chance
of failure!
Any thoughts?
Regards,
Ruth
-
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
Please help me save my data
Hello list. I have a spot of trouble with a RAID5 array of mine, and I thought maybe you could help me. This is the story so far: * I bought 10 external USB drives. This seemed like a good idea, they are cheap, they are hot-pluggable and they are fast enough. * I set them up in two RAID5 arrays, which I set up as LVM pv's. Then I created an LVM vg out of these and an LVM lv out of the vg. * I encrypted this lv and formatted it with an xfs fs. This all worked perfectly fine, until I realized how bad these drives and this USB controller work with ehci_hcd. In short, the devices get reset all the time. And each time they get reset, everything stops for a while. Nothing strange and no showstopper here. But the really bad thing is when they reset in some extra-bad way, and get dropped completely. What happens then is that the RAID5 system drops them, and they get reincarnated with a new device name. /dev/sdi becomes suddenly /dev/sdn or something similarly horrbile. And since I (up until yesterday) didnt know about write-intent bitmaps each resync took around 10 hours. Plenty of time for ANOTHER disk to fail and get dropped. This I usually solved by doing mdadm -S and then mdadm -A -f. Yesterday, however, I was feeling extra clever, and I just did mdadm -a /dev/md1 /dev/sdn1. This was a huge mistake. What had happened, I now realized, was this: * /dev/md1 is fine * /dev/sdX1 drops, and /dev/md1 is degraded * I re-add /dev/sdX1 in its new guise, and /dev/md1 is resyncing with 4 working drives and one spare * /dev/sdY1 drops, and /dev/md1 stops * I re-add /dev/sdY1 in its new guise, and mdadm marks it as a SPARE. * I suddenly have an array with 3 working drives and 2 spares where I know that one spare is in fact synced and ready to go, since the array stopped the moment it failed. Also, I dont know any longer WHERE in the array the synced but spare-marked drive should go. I know that the working drives are 0, 2 and 4, but not where the synced spare drive should go. So, what I want to do is: * Mark the synced spare drive as working and in position 1 * Assemble the array without the unsynced spare and check if this provides consistent data * If it didnt, I want to mark the synced spare as working and in position 3, and try the same thing again * When I have it working, I just want to add the unsynced spare and let it sync normally * Then I will create a write-intent bitmap to avoid the dangerously long sync times, and also buy a new USB controller hoping that it will solve my problems So, do you guys have any idea how I can do this? mdadm doesnt support changing the superblock in such a free hand manner... Please help me save this data :/ It is precious to me :.( regards, //Martin Kihlgren - 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
Please help me save my data
Hello list. I have a spot of trouble with a RAID5 array of mine, and I thought maybe you could help me. This is the story so far: * I bought 10 external USB drives. This seemed like a good idea, they are cheap, they are hot-pluggable and they are fast enough. * I set them up in two RAID5 arrays, which I set up as LVM pv's. Then I created an LVM vg out of these and an LVM lv out of the vg. * I encrypted this lv and formatted it with an xfs fs. This all worked perfectly fine, until I realized how bad these drives and this USB controller work with ehci_hcd. In short, the devices get reset all the time. And each time they get reset, everything stops for a while. Nothing strange and no showstopper here. But the really bad thing is when they reset in some extra-bad way, and get dropped completely. What happens then is that the RAID5 system drops them, and they get reincarnated with a new device name. /dev/sdi becomes suddenly /dev/sdn or something similarly horrbile. And since I (up until yesterday) didnt know about write-intent bitmaps each resync took around 10 hours. Plenty of time for ANOTHER disk to fail and get dropped. This I usually solved by doing mdadm -S and then mdadm -A -f. Yesterday, however, I was feeling extra clever, and I just did mdadm -a /dev/md1 /dev/sdn1. This was a huge mistake. What had happened, I now realized, was this: * /dev/md1 is fine * /dev/sdX1 drops, and /dev/md1 is degraded * I re-add /dev/sdX1 in its new guise, and /dev/md1 is resyncing with 4 working drives and one spare * /dev/sdY1 drops, and /dev/md1 stops * I re-add /dev/sdY1 in its new guise, and mdadm marks it as a SPARE. * I suddenly have an array with 3 working drives and 2 spares where I know that one spare is in fact synced and ready to go, since the array stopped the moment it failed. Also, I dont know any longer WHERE in the array the synced but spare-marked drive should go. I know that the working drives are 0, 2 and 4, but not where the synced spare drive should go. So, what I want to do is: * Mark the synced spare drive as working and in position 1 * Assemble the array without the unsynced spare and check if this provides consistent data * If it didnt, I want to mark the synced spare as working and in position 3, and try the same thing again * When I have it working, I just want to add the unsynced spare and let it sync normally * Then I will create a write-intent bitmap to avoid the dangerously long sync times, and also buy a new USB controller hoping that it will solve my problems So, do you guys have any idea how I can do this? mdadm doesnt support changing the superblock in such a free hand manner... Please help me save this data :/ It is precious to me :.( regards, //Martin Kihlgren - 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?
Hello Neil Luca ,
On Fri, 8 Sep 2006, Luca Berra wrote:
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.
Kuca , Thank you for posting this snippet .
Neil , Might changing ,
can be given as max which means to choose the largest size that
To
can be given as 'max' which means to choose the largest size that
help those reading this be aware that this is a 'string' to add to the
end of --size= ? Also if there are other keywords not quoted ('') this
might be a good opertunity . ;-) Tia , JimL
--
+--+
| James W. Laferriere | SystemTechniques | Give me VMS |
| NetworkEngineer | 3600 14th Ave SE #20-103 | Give me Linux |
| [EMAIL PROTECTED] | Olympia , WA. 98501 | only on AXP |
+--+
Re: Messed up creating new array...
On 9/8/06, Ruth Ivimey-Cook [EMAIL PROTECTED] wrote: I messed up slightly when creating a new 6-disk raid6 array, and am wondering if there is a simple answer. The problem is that I didn't partition the drives, but simply used the whole drive. All drives are of the same type and using the Supermicro SAT2-MV8 controller. This should work: 1. Unmount filesystem. 2. Shrink file system to something a bit smaller. Since it's a big array, 1GB should give you plenty of room. 3. Shrink raid array to something in between the new fs size and old fs size. Make sure you don't shrink it smaller than the filesystem! 4. Remove a disk from the array (fail/remove) 5. Partition disk 6. Add partition back to array 7. Repeat steps 4-6 for all disks in the array. 8. Now the whole array should be on partitions. Grow the raid array back to max. 9. Grow filesystem to the partition size. -Dave - 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
UUID's
If I have specified an array in mdadm.conf using UUID's: ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371 and I replace a failed drive in the array, will the new drive be given the previous UUID, or do I need to upate the mdadm.conf entry? Regards, Richard - 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: UUID's
On Sat, 9 Sep 2006, Richard Scobie wrote: If I have specified an array in mdadm.conf using UUID's: ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371 and I replace a failed drive in the array, will the new drive be given the previous UUID, or do I need to upate the mdadm.conf entry? once you do the mdadm /dev/mdX -a /dev/newdrive the new drive will have the UUID. no need to update the mdadm.conf for the UUID... however if you're using DEVICE foo where foo is not partitions then you should make sure foo includes the new drive. (DEVICE partitions is recommended.) -dean - 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: UUID's
dean gaudet wrote: On Sat, 9 Sep 2006, Richard Scobie wrote: If I have specified an array in mdadm.conf using UUID's: ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371 and I replace a failed drive in the array, will the new drive be given the previous UUID, or do I need to upate the mdadm.conf entry? once you do the mdadm /dev/mdX -a /dev/newdrive the new drive will have the UUID. no need to update the mdadm.conf for the UUID... however if you're using DEVICE foo where foo is not partitions then you should make sure foo includes the new drive. (DEVICE partitions is recommended.) Thanks Dean, I am setting up a Fedora 5 machine, which I configured to use RAID1 for all partions during the install and the resulting madadm.conf it generated is: DEVICE partitions MAILADDR root ARRAY /dev/md3 super-minor=3 ARRAY /dev/md1 super-minor=1 ARRAY /dev/md4 super-minor=4 ARRAY /dev/md0 super-minor=0 ARRAY /dev/md2 super-minor=2 To remove all doubt about what is assembled where, I though going to: DEVICE partitions MAILADDR root ARRAY /dev/md3 UUID=xyz etc. would be more secure. Is this correct thinking on my part? Regards, Richard - 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
Check/repair on composite RAID
If I have a RAID 10, comprising a RAID 0, /dev/md3 made up of RAID1, /dev/md1 and RAID1, /dev/md2 and I do an: echo repair /sys/block/md3/md/sync_action will this run simultaneous repairs on the the underlying RAID 1's, or should seperate repairs be done to md1 and 2? Thanks for any assistence. Regards, Richard - 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
2.6.18-rc5-mm1 - bd_claim_by_disk oops
I got the following on 2.6.18-rc5-mm1 when trying to lvextend a test logical volume that I had just created. This came about because I have been trying to expand some LVs on my system, which are based on a VG ontop of an MD mirror pair. It's an SMP box too if that means anything. device-mapper: table: 253:3: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:3: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:2: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table BUG: unable to handle kernel paging request at virtual address 6f72702e printing eip: c018505b *pde = Oops: [#1] 4K_STACKS SMP last sysfs file: /block/dm-2/removable Modules linked in: rfcomm l2cap bluetooth sbp2 i2c_piix4 ohci1394 evdev snd_ens1 371 snd_rawmidi snd_ac97_codec snd_ac97_bus i2c_core snd_pcm snd_timer snd sound core snd_page_alloc ieee1394 uhci_hcd ohci_hcd usb_storage CPU:1 EIP:0060:[c018505b]Not tainted VLI EFLAGS: 00010292 (2.6.18-rc5-mm1 #1) EIP is at bd_claim_by_disk+0x9b/0x1c0 eax: e6622ba0 ebx: 6f72702e ecx: c16decbc edx: 6f72702e esi: edi: e4a11220 ebp: c16dec80 esp: c62e1ca4 ds: 007b es: 007b ss: 0068 Process lvextend (pid: 2926, ti=c62e1000 task=dccfa580 task.ti=c62e1000) Stack: c047cefa c16dec8c c16dec80 e3e31920 d1130e80 c16dec80 c035f9c8 fff4 e128d160 0090 e3e31920 c036040c f0a5915c c042bf66 c62e1d50 c62e1d4c c0500f0c e128d160 f0a5915c f0a1b080 e128d0c0 0001 c0500f0c Call Trace: [c035f9c8] open_dev+0x48/0x80 [c036040c] dm_get_device+0x20c/0x480 [c0243537] vsscanf+0x447/0x490 [c0360ca9] linear_ctr+0x99/0x110 [c035ff0d] dm_table_add_target+0x17d/0x2e0 [c0361e6a] table_load+0xba/0x1d0 [c0362b9d] ctl_ioctl+0x22d/0x2a0 [c028b594] n_tty_receive_buf+0x324/0x1070 [c0361db0] table_load+0x0/0x1d0 [c016c2d8] do_ioctl+0x78/0x90 [c016c34c] vfs_ioctl+0x5c/0x2b0 [c016c5dd] sys_ioctl+0x3d/0x70 [c0102f33] syscall_call+0x7/0xb === Code: 3c 8b 13 0f 18 02 90 8d 4d 3c 39 cb 0f 84 24 01 00 00 8b 47 0c 3b 43 0c 75 0f e9 ab 00 00 00 90 3b 43 0c 0f 84 a1 00 00 00 89 d3 8b 12 0f 18 02 90 39 cb 75 eb e8 d6 a9 0b 00 85 c0 89 47 0c 0f EIP: [c018505b] bd_claim_by_disk+0x9b/0x1c0 SS:ESP 0068:c62e1ca4 - 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
