Re: New FAQ entry? (was IBM xSeries stop responding during RAID1 reconstruction)
personally, I don't see any point to worrying about the default, compile-time or boot time: for f in `find /sys/block/* -name scheduler`; do echo cfq $f; done I tested this case: - reboot as per power failure (RAID goes dirty) - RAID start resyncing as soon as the kernel assemble it - every disk activity is blocked, even DHCP failed! - host services are unavailable This is why I changed the kernel default. -- Niccolo Rigacci Firenze - Italy Iraq, missione di pace: 38475 morti - www.iraqbodycount.net - 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: read perfomance patchset
On Monday June 19, [EMAIL PROTECTED] wrote: Neil hello if i am not mistaken here: in first instance of : if(bi) ... ... you return without setting to NULL Yes, you are right. Thanks. And fixing that bug removes the crash. However I've been doing a few tests and it is hard to measure much improvement, which is strange. I can maybe see a 1% improvement but that could just be noise. I do some more and see if I can find out what is happening. Interestingly, with a simple dd if=/dev/md1 of=/dev/null bs=1024k test, 2.6.16 is substantially faster (10%) than 2.6.17-rc6-mm2 before that patches are added. There is something weird there. Have you done any testing? NeilBrown - 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: Ok to go ahead with this setup?
Christian Pernegger wrote: Intel SE7230NH1-E mainboard Pentium D 930 HPA recently said that x86_64 CPUs have better RAID5 performance. Promise Ultra133 TX2 (2ch PATA) - 2x Maxtor 6B300R0 (300GB, DiamondMax 10) in RAID1 Onboard Intel ICH7R (4ch SATA) - 4x Western Digital WD5000YS (500GB, Caviar RE2) in RAID5 Is it a NAS kind of device? In that case, drop the 2x 300GB disks and get 6x 500GB instead. You can partition those so that you have a RAID1 spanning the first 10GB of all 6 drives for use as the system partition, and use the rest in a RAID5. * Does this hardware work flawlessly with Linux? No clue. * Is it advisable to boot from the mirror? Should work. Would the box still boot with only one of the disks? If you configure things correctly - better test it. * Can I use EVMS as a frontend? Yes. Does it even use md or is EVMS's RAID something else entirely? EVMS uses a lot of underlying software, MD being one component. * Should I use the 300s as a single mirror, or span multiple ones over the two disks? What would the purpose be? * Am I even correct in assuming that I could stick an array in another box and have it work? Work for what? Comments welcome Get gigabit nics, in case you want to fiddle with iSCSI? :-). - 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: Ok to go ahead with this setup?
Molle Bestefich wrote: Christian Pernegger wrote: Intel SE7230NH1-E mainboard Pentium D 930 HPA recently said that x86_64 CPUs have better RAID5 performance. Actually, anything with SSE2 should be OK. -hpa - 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
Large single raid and XFS or two small ones and EXT3?
Dear All, I have a Linux storage server containing 16x750GB drives - so 12TB raw space. If I make them into a single RAID5 array, then it appears my only choice for a filesystem is XFS - as EXT3 won't really handle partitions over 8TB. Alternatively, I could split each drive into 2 partitions and have 2 RAID5 arrays, then put an EXT3 on each one. Can anybody advise the pros and cons of these two approaches with regard to stability, reliability and performance? The store is to be used for files which will have an even split of: 33% approx 2MB in size 33% approx 50KB in size 33% approx 2KB in size Also: - I am running a 2.6.15-1 stock FC5 kernel. Would there be any RAID benefits in me upgrading to the latest 2.6.16 kernel? (don't want to do this unless there is very good reason to) - I am running mdadm 2.3.1. Would there be any benefits for me in upgrading to mdadm v2.5? - I have read good things about bitmaps. Are these production ready? Any advice/caveats? Many thanks for reading, Chris Allen. - 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: Large single raid and XFS or two small ones and EXT3?
On Thu, 22 Jun 2006, Chris Allen wrote: Dear All, I have a Linux storage server containing 16x750GB drives - so 12TB raw space. Just one thing - Do you want to use RAID-5 or RAID-6 ? I just ask, as with that many drives (and that much data!) the possibilities of a 2nd drive failure is increasing, and personally, wherever I can, I take the hit these days, and have used RAID-6 for some time... drives are cheap, even the 750GB behemoths! If I make them into a single RAID5 array, then it appears my only choice for a filesystem is XFS - as EXT3 won't really handle partitions over 8TB. I can't help with this though - I didn't realise ext3 had such a limitation though! Gordon - 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: Large single raid and XFS or two small ones and EXT3?
H. Peter Anvin wrote: Gordon Henderson wrote: On Thu, 22 Jun 2006, Chris Allen wrote: Dear All, I have a Linux storage server containing 16x750GB drives - so 12TB raw space. Just one thing - Do you want to use RAID-5 or RAID-6 ? I just ask, as with that many drives (and that much data!) the possibilities of a 2nd drive failure is increasing, and personally, wherever I can, I take the hit these days, and have used RAID-6 for some time... drives are cheap, even the 750GB behemoths! If I make them into a single RAID5 array, then it appears my only choice for a filesystem is XFS - as EXT3 won't really handle partitions over 8TB. I can't help with this though - I didn't realise ext3 had such a limitation though! 16 TB (2^32 blocks) should be the right number. It should be, but mkfs.ext3 won't let me create a filesystem bigger than 8TB. It appears that the only way round this is through kernel patches, and, as this is a production machine, I'd rather stick to mainstream releases and go for one of the above solutions. - 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: Ok to go ahead with this setup?
Pentium D 930 HPA recently said that x86_64 CPUs have better RAID5 performance. Good to know. I did intend to use Debian-amd64 anyway. Is it a NAS kind of device? Yes, mostly. It also runs a caching NNTP proxy and drives our networked audio players :) Personal file server describes it best, I think. In that case, drop the 2x 300GB disks and get 6x 500GB instead. You can partition those so that you have a RAID1 spanning the first 10GB of all 6 drives for use as the system partition, and use the rest in a RAID5. Good idea, it's just that I already have the listed disks, and I need at least 150 GB effective capacity on the mirror for important work data, not just the OS. Anything specific wrong with the Maxtors? * Should I use the 300s as a single mirror, or span multiple ones over the two disks? What would the purpose be? I read somewhere that this could reduce rebuild time when a disk (partition in this case) is kicked offline because of a timeout or somesuch. Sounds a bit fishy, which is why I'm asking. * Am I even correct in assuming that I could stick an array in another box and have it work? Work for what? Well, access to the data. The point of the whole exercise is that I don't want to be cut off from my data, just because a part of the host (not the disks) died. Get gigabit nics, in case you want to fiddle with iSCSI? :-) The board has one or two Intel Gb NICs, they usually work fine ... And iSCSI sounds way too expensive. :) Thanks, C. - 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 raid5 disk replacement success (using bitmap + raid1)
Hi Dean Thanks a lot for sharing this. I am not quite understand about these 2 commands. Why we want to add a pre-failing disk back to md4? mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 Ming On Sun, 2006-04-23 at 18:40 -0700, dean gaudet wrote: i had a disk in a raid5 which i wanted to clone onto the hot spare... without going offline and without long periods without redundancy. a few folks have discussed using bitmaps and temporary (superblockless) raid1 mappings to do this... i'm not sure anyone has tried / reported success though. this is my success report. setup info: - kernel version 2.6.16.9 (as packaged by debian) - mdadm version 2.4.1 - /dev/md4 is the raid5 - /dev/sde1 is the disk in md4 i want to clone from - /dev/sdh1 is the hot spare from md4, and is the clone target - /dev/md5 is an unused md device name here are the exact commands i issued: 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... mdadm /dev/md4 -f /dev/md5 -r /dev/md5 mdadm --stop /dev/md5 mdadm /dev/md4 --re-add /dev/sdh1 mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 this sort of thing shouldn't be hard to script :) the only times i was without full redundancy was briefly between the -r and --re-add commands... and with bitmap support the raid5 resync for each of those --re-adds was essentially zero. thanks Neil (and others)! -dean p.s. it's absolutely necessary to use --build for the temporary raid1 ... if you use --create mdadm will rightfully tell you it's already a raid component and if you --force it then you'll trash the raid5 superblock and it won't fit into the raid5 any more... - 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 - 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 raid5 disk replacement success (using bitmap + raid1)
well that part is optional... i wasn't replacing the disk right away anyhow -- it had just exhibited its first surface error during SMART and i thought i'd try moving the data elsewhere just for the experience of it. -dean On Thu, 22 Jun 2006, Ming Zhang wrote: Hi Dean Thanks a lot for sharing this. I am not quite understand about these 2 commands. Why we want to add a pre-failing disk back to md4? mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 Ming On Sun, 2006-04-23 at 18:40 -0700, dean gaudet wrote: i had a disk in a raid5 which i wanted to clone onto the hot spare... without going offline and without long periods without redundancy. a few folks have discussed using bitmaps and temporary (superblockless) raid1 mappings to do this... i'm not sure anyone has tried / reported success though. this is my success report. setup info: - kernel version 2.6.16.9 (as packaged by debian) - mdadm version 2.4.1 - /dev/md4 is the raid5 - /dev/sde1 is the disk in md4 i want to clone from - /dev/sdh1 is the hot spare from md4, and is the clone target - /dev/md5 is an unused md device name here are the exact commands i issued: 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... mdadm /dev/md4 -f /dev/md5 -r /dev/md5 mdadm --stop /dev/md5 mdadm /dev/md4 --re-add /dev/sdh1 mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 this sort of thing shouldn't be hard to script :) the only times i was without full redundancy was briefly between the -r and --re-add commands... and with bitmap support the raid5 resync for each of those --re-adds was essentially zero. thanks Neil (and others)! -dean p.s. it's absolutely necessary to use --build for the temporary raid1 ... if you use --create mdadm will rightfully tell you it's already a raid component and if you --force it then you'll trash the raid5 superblock and it won't fit into the raid5 any more... - 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 - 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 raid5 disk replacement success (using bitmap + raid1)
ic. thx for clarifying. ming On Thu, 2006-06-22 at 17:09 -0700, dean gaudet wrote: well that part is optional... i wasn't replacing the disk right away anyhow -- it had just exhibited its first surface error during SMART and i thought i'd try moving the data elsewhere just for the experience of it. -dean On Thu, 22 Jun 2006, Ming Zhang wrote: Hi Dean Thanks a lot for sharing this. I am not quite understand about these 2 commands. Why we want to add a pre-failing disk back to md4? mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 Ming On Sun, 2006-04-23 at 18:40 -0700, dean gaudet wrote: i had a disk in a raid5 which i wanted to clone onto the hot spare... without going offline and without long periods without redundancy. a few folks have discussed using bitmaps and temporary (superblockless) raid1 mappings to do this... i'm not sure anyone has tried / reported success though. this is my success report. setup info: - kernel version 2.6.16.9 (as packaged by debian) - mdadm version 2.4.1 - /dev/md4 is the raid5 - /dev/sde1 is the disk in md4 i want to clone from - /dev/sdh1 is the hot spare from md4, and is the clone target - /dev/md5 is an unused md device name here are the exact commands i issued: 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... mdadm /dev/md4 -f /dev/md5 -r /dev/md5 mdadm --stop /dev/md5 mdadm /dev/md4 --re-add /dev/sdh1 mdadm --zero-superblock /dev/sde1 mdadm /dev/md4 -a /dev/sde1 this sort of thing shouldn't be hard to script :) the only times i was without full redundancy was briefly between the -r and --re-add commands... and with bitmap support the raid5 resync for each of those --re-adds was essentially zero. thanks Neil (and others)! -dean p.s. it's absolutely necessary to use --build for the temporary raid1 ... if you use --create mdadm will rightfully tell you it's already a raid component and if you --force it then you'll trash the raid5 superblock and it won't fit into the raid5 any more... - 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 - 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: Is shrinking raid5 possible?
Neil Brown wrote: On Monday June 19, [EMAIL PROTECTED] wrote: Hi, I'd like to shrink the size of a RAID5 array - is this possible? My first attempt shrinking 1.4Tb to 600Gb, mdadm --grow /dev/md5 --size=629145600 gives mdadm: Cannot set device size/shape for /dev/md5: No space left on device Yep. The '--size' option refers to: Amount (in Kibibytes) of space to use from each drive in RAID1/4/5/6. This must be a multiple of the chunk size, and must leave about 128Kb of space at the end of the drive for the RAID superblock. (from the man page). So you were telling md to use the first 600GB of each device in the array, and it told you there wasn't that much room. If your array has N drives, you need to divide the target array size by N-1 to find the target device size. So if you have a 5 drive array, then you want --size=157286400 May I say in all honesty that making people do that math instead of the computer is a really bad user interface? Good, consider it said. An means to just set the target size of the resulting raid device would be a LOT less likely to cause bad user input, and while I'm complaining it should inderstand suffices 'k', 'm', and 'g'. Far easier to use for the case where you need, for instance, 10G of storage for a database, tell mdadm what devices to use and what you need (and the level of course) and let the computer figure out the details, rounding up, leaving 128k, and phase of the moon if you decide to use it. Sorry, I think the current approach is baaad human interface. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: Is shrinking raid5 possible?
On Thursday June 22, [EMAIL PROTECTED] wrote: Neil Brown wrote: On Monday June 19, [EMAIL PROTECTED] wrote: Hi, I'd like to shrink the size of a RAID5 array - is this possible? My first attempt shrinking 1.4Tb to 600Gb, mdadm --grow /dev/md5 --size=629145600 gives mdadm: Cannot set device size/shape for /dev/md5: No space left on device Yep. The '--size' option refers to: Amount (in Kibibytes) of space to use from each drive in RAID1/4/5/6. This must be a multiple of the chunk size, and must leave about 128Kb of space at the end of the drive for the RAID superblock. (from the man page). So you were telling md to use the first 600GB of each device in the array, and it told you there wasn't that much room. If your array has N drives, you need to divide the target array size by N-1 to find the target device size. So if you have a 5 drive array, then you want --size=157286400 May I say in all honesty that making people do that math instead of the computer is a really bad user interface? Good, consider it said. An means to just set the target size of the resulting raid device would be a LOT less likely to cause bad user input, and while I'm complaining it should inderstand suffices 'k', 'm', and 'g'. Let me put another perspective on this. Why would you ever want to reduce the size of a raid5 in this way? The only reason that I can think of is that you want to repartition each device to use a smaller partition for the raid5, and free up some space for something else. If that is what you are doing, you will have already done the math and you will know what size you want your final partitions to be, so setting the device size is just as easy as setting the array size. If you really are interested in array size and have no interest in recouping the wasted space on the drives, then there would be no point in shrinking the array (that I can think of). Just 'mkfs' a filesystem to the desired size and ignore the rest of the array. In short, reducing a raid5 to a particular size isn't something that really makes sense to me. Reducing the amount of each device that is used does - though I would much more expect people to want to increase that size. If Paul really has a reason to reduce the array to a particular size then fine. I'm mildly curious, but it's his business and I'm happy for mdadm to support it, though indirectly. But I strongly suspect that most people who want to resize their array will be thinking in terms of the amount of each device that is used, so that is how mdadm works. Far easier to use for the case where you need, for instance, 10G of storage for a database, tell mdadm what devices to use and what you need (and the level of course) and let the computer figure out the details, rounding up, leaving 128k, and phase of the moon if you decide to use it. mdadm is not intended to be a tool that manages your storage for you. If you want that, then I suspect EVMS is what you want (though I am only guessing - I've never used it). mdadm it a tool that enables YOU to manage your storage. NeilBrown Sorry, I think the current approach is baaad human interface. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: Is shrinking raid5 possible?
Neil Brown wrote: In short, reducing a raid5 to a particular size isn't something that really makes sense to me. Reducing the amount of each device that is used does - though I would much more expect people to want to increase that size. If Paul really has a reason to reduce the array to a particular size then fine. I'm mildly curious, but it's his business and I'm happy for mdadm to support it, though indirectly. But I strongly suspect that most people who want to resize their array will be thinking in terms of the amount of each device that is used, so that is how mdadm works. By way of explanation, I was doing exactly what you thought - I had a single ext3 filesystem on a raid5 device, and wanted to split it into two filesystems. I'm not using LVM since it appears to affect read performance quite severely. I guess there may be other ways of doing this but this seemed the most straightforward. Incidentally, it wasn't clear to me what to do after shrinking the raid5 device. My initial try at taking it offline and repartitioning all the disks at once didn't work - I think because the superblocks became 'lost'. I eventually realized I should go through a fail-remove-repartition-add-recover cycle for each disk in turn with the array online. It took a long time but worked in the end. Would repartitioning them all at once have worked if I had chosen to have the superblocks at the beginning of the partitions (v1.1 or 1.2 superblocks)? As for Bill's comment about the mdadm interface, what probably would have helped me the most is if the man page had had from each drive in bold, flashing and preferably two-foot tall letters :-). A more practical suggestion is if the error message had not been No space left on device but something like Maximum space available on each device is then I would have quickly realized my mistake. As Neil points out, you have to 'do the math' anyway when partitioning. Cheers, Paul - 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: Ok to go ahead with this setup?
Molle Bestefich wrote: Christian Pernegger wrote: Anything specific wrong with the Maxtors? No. I've used Maxtor for a long time and I'm generally happy with them. They break now and then, but their online warranty system is great. I've also been treated kindly by their help desk - talked to a cute gal from Maxtor in Ireland over the phone just yesterday ;-). Then again, they've just been acquired by Seagate, or so, so things may change for the worse, who knows. I'd watch out regarding the Western Digital disks, apparently they have a bad habit of turning themselves off when used in RAID mode, for some reason: http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/1980/ I have exactly the opposite experience. More than 50% of Maxtor drives fail inside 18 months; WDs seem to be really solid. -hpa - 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: New FAQ entry? (was IBM xSeries stop responding during RAID1 reconstruction)
Niccolo Rigacci wrote: personally, I don't see any point to worrying about the default, compile-time or boot time: for f in `find /sys/block/* -name scheduler`; do echo cfq $f; done I tested this case: - reboot as per power failure (RAID goes dirty) - RAID start resyncing as soon as the kernel assemble it - every disk activity is blocked, even DHCP failed! - host services are unavailable This is why I changed the kernel default. Changing on the command line assumes that you built all of the schedulers in... but making that assumption, perhaps the correct fail-safe is to have cfq as the default, and at the end of rc.local check for rebuild, and if everything is clean change to whatever work best at the end of the boot. If the raid is not clean stay with cfq. Has anyone tried deadline for this? I think I had this as deafult and didn't hand on a raid5 fail/rebuild. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: Ok to go ahead with this setup?
Christian Pernegger wrote: Hi list! Having experienced firsthand the pain that hardware RAID controllers can be -- my 3ware 7500-8 died and it took me a week to find even a 7508-8 -- I would like to switch to kernel software RAID. Here's a tentative setup: Intel SE7230NH1-E mainboard Pentium D 930 2x1GB Crucial 533 DDR2 ECC Intel SC5295-E enclosure Promise Ultra133 TX2 (2ch PATA) - 2x Maxtor 6B300R0 (300GB, DiamondMax 10) in RAID1 Onboard Intel ICH7R (4ch SATA) - 4x Western Digital WD5000YS (500GB, Caviar RE2) in RAID5 * Does this hardware work flawlessly with Linux? * Is it advisable to boot from the mirror? Would the box still boot with only one of the disks? Let me say this about firmware mirror: while virtually every BIOS will boot the next disk if the first fails, some will not fail over if the first drive is returning a parity but still returning data. Take that data any way you want, drive failure at power cycle is somewhat more likely than failure while running. * Can I use EVMS as a frontend? Does it even use md or is EVMS's RAID something else entirely? * Should I use the 300s as a single mirror, or span multiple ones over the two disks? * Am I even correct in assuming that I could stick an array in another box and have it work? Comments welcome Thanks, Chris - 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 -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: Ok to go ahead with this setup?
Molle Bestefich wrote: Christian Pernegger wrote: Anything specific wrong with the Maxtors? No. I've used Maxtor for a long time and I'm generally happy with them. They break now and then, but their online warranty system is great. I've also been treated kindly by their help desk - talked to a cute gal from Maxtor in Ireland over the phone just yesterday ;-). Then again, they've just been acquired by Seagate, or so, so things may change for the worse, who knows. I'd watch out regarding the Western Digital disks, apparently they have a bad habit of turning themselves off when used in RAID mode, for some reason: http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/1980/ Based on three trials in five years, I'm happy with WD and Seagate. WD didn't ask when I bought it, just the serial for manufacturing date. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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
Curious code in autostart_array
Hi, guys: My copy of 2.6.17-rc5 has the following code in autostart_array(): mdp_disk_t *desc = sb-disks + i; dev_t dev = MKDEV(desc-major, desc-minor); if (!dev) continue; if (dev == startdev) continue; if (MAJOR(dev) != desc-major || MINOR(dev) != desc-minor) continue; Under what conditions do you think the last if() statement can fire? What is its purpose? This looks like an attempt to detect bit clipping. But what exactly? Cheers, -- Pete - 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: Curious code in autostart_array
Pete Zaitcev wrote: Hi, guys: My copy of 2.6.17-rc5 has the following code in autostart_array(): mdp_disk_t *desc = sb-disks + i; dev_t dev = MKDEV(desc-major, desc-minor); if (!dev) continue; if (dev == startdev) continue; if (MAJOR(dev) != desc-major || MINOR(dev) != desc-minor) continue; Under what conditions do you think the last if() statement can fire? What is its purpose? This looks like an attempt to detect bit clipping. But what exactly? It can fire if either desc-major or desc-minor overflow the respective fields in dev_t. Unfortunately, it's not guaranteed to do so. -hpa - 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: Curious code in autostart_array
On Fri, 23 Jun 2006 14:46:13 +1000, Neil Brown [EMAIL PROTECTED] wrote: dev_t dev = MKDEV(desc-major, desc-minor); if (MAJOR(dev) != desc-major || MINOR(dev) != desc-minor) continue; desc-major and desc-minor have been read of the disk, so their values cannot be trusted. Oh, right. Sorry. -- Pete - 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
