Re: NVRAM support
Hi, My intention was not to use a NVRAM device for swap. Enterprise storage systems use NVRAM for better data protection/faster recovery in case of a crash. Modern CPUs can do RAID calculation very fast. But Linux RAID is vulnerable when a crash during a write operation occurs. E.g. Data and parity write requests are issued in parallel but only one finishes. This will lead to inconsistent data. It will be undetected and can not be repaired. Right? How can journaling be implemented within linux-raid? I have seen a paper that tries this in cooperation with a file system: „Journal-guided Resynchronization for Software RAID“ www.cs.wisc.edu/adsl/Publications But I would rather see a solution within md so that other file systems or LVM can be used on top of md. Regards, Mirko Erik Mouw schrieb: On Fri, Feb 10, 2006 at 05:02:02PM -0800, dean gaudet wrote: On Fri, 10 Feb 2006, Bill Davidsen wrote: Erik Mouw wrote: You could use it for an external journal, or you could use it as a swap device. Let me concur, I used external journal on SSD a decade ago with jfs (AIX). If you do a lot of operations which generate journal entries, file create, delete, etc, then it will double your performance in some cases. Otherwise it really doesn't help much, use as a swap device might be more helpful depending on your config. it doesn't seem to make any sense at all to use a non-volatile external memory for swap... swap has no purpose past a power outage. No, but it is a very fast swap device. Much faster than a hard drive. Erik - 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 5 inaccessible - continued
I tried this one yesterday, with 2.6.15 that is. The same thing happened, at the bad block sectors it tried and skipped some but after a minute or two it stopped again. Hmmmz. Krekna 2006/2/14, Mike Hardy [EMAIL PROTECTED]: Krekna Mektek wrote: The dd actually succeeded, and did finish the job in about one day. The badblocks were found after about the first 7 Gigs. Is this a 3-disk raid5 array? With two healthy disks and one bad disk? If so, then what you really want is a new kernel (2.6.15+? 2.6.14+?) that has raid5 read-error-handling code in it. Neil just coded that up. If it's missing a disk and has a disk with bad sectors, then you've already lost data, but you could use a combination of smart tests and dd to zero out those specific sectors (and only those sectors...) then sync a new disk up with the array... -Mike - 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 5 inaccessible - continued
Hi David, Thank you. I will give ddrescue a shot then. But what is it different than a dd with the noerror conversion? Krekna 2006/2/14, David Greaves [EMAIL PROTECTED]: Krekna Mektek wrote: I want to rebuilt from the good one and the faulty one. That's why I wanted to dd the disk to an image file, but it complains it has no boot sector. I did the folowing: dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img You could try doing this again using ddrescue (google if you need to install it): ddrescue dev/hdd1 /mnt/hdb1/Faulty-RAIDDisk.img /mnt/hdb1/Faulty-RAIDDisk.log Then do it again using -r10 (to increase the retries on the faulty sectors) ddrescue -r10 dev/hdd1 /mnt/hdb1/Faulty-RAIDDisk.img /mnt/hdb1/Faulty-RAIDDisk.log This will be much quicker because the log file contains details of the faulty sectors. With luck (mucho luck) you may not even lose data. David -- - 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 5 inaccessible - continued
Am Dienstag, 14. Februar 2006 11:35 schrieb Krekna Mektek: [...] Actually, /dev/hdd1 partition is 390708801 blocks, the disk itself is a Hitachi 400GB disk. So this is 390708801 blocks of 1024 bytes. This is according to my calculation 400085812224 bytes. The Faulty-RAIDDisk.img is according to my ls -l 400085771264 bytes. So it looks like they are quite the same, and the difference between the two is 40960 bytes. These are 40 blocks, so 36 are missing? The dd actually succeeded, and did finish the job in about one day. The badblocks were found after about the first 7 Gigs. Is there no way like the conv=noerror for mdadm, to just continue? Can I restore the superblock on the .img file somehow? Is it probably save to --zero-superblock all the three disks and that the RAID array will create two new superblocks (Leaving the spare out, because its probably out of date). I can do the dd again, but I think it will do the same thing, because it finished 'succesfully'. The superblock is at the end of the disk I read, about the last 64-128K or something. My experience is that dd conv=noerror doesn't do the job correctly!! It still won't write a block that it cannot read. Please use dd_rescue -A /dev/hdd1 /mnt/hdb1/Faulty-RAIDDisk.img instead. See dd_rescue --help. ADEVICE /dev/hdb1 /dev/hdc1 /dev/loop0 ARRAY /dev/md0 devices=/dev/hdb1,/dev/hdc1,/dev/loop0 another thing: /mnt/hdb1/ is not the same hdb1, you are using in the raid5, is it? It might be a bad idea to mount /dev/hdb1, write to it, and afterwards assemble the array with hdb1 being part of it ... Extra bad, if loop0 points to a file on hdb1 ?? However, if you did dd to a file on the partition, that should be part of the degraded raid5 array, I guess your data is already gone ... Good luck Burkhard - 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 07:50:28AM +0100, Luca Berra wrote: 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 So the md5 array will reconstruct itself after initial bootup where the kernel reconstructs the raid1 (as well as it can) for booting? All md partitions are of type fd (Linux raid autodetect). this is surprisingly not at all relevant Awww. But I like it when the kernel just, well, does it all and makes it all ready. :) -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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
WOW
You have got to look at this. Its outstanding. Its a major new business. http://www.legalrevenueservice.com/ Liz Want to not receive info in the future? [EMAIL PROTECTED] ... - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID 5 inaccessible - continued
Er,,, no :) This was on another machine, luckily, I am not that stupid. I was using /dev/hdb in that one, sorry to be a bit unclear about that. Also, I usually sit on my hands for a sec when I do such powerfull commands. Good, so I make some chances then with dd_rescue, I'll let you know then, I have to try this tonight. Krekna 2006/2/15, Burkhard Carstens [EMAIL PROTECTED]: Am Dienstag, 14. Februar 2006 11:35 schrieb Krekna Mektek: [...] Actually, /dev/hdd1 partition is 390708801 blocks, the disk itself is a Hitachi 400GB disk. So this is 390708801 blocks of 1024 bytes. This is according to my calculation 400085812224 bytes. The Faulty-RAIDDisk.img is according to my ls -l 400085771264 bytes. So it looks like they are quite the same, and the difference between the two is 40960 bytes. These are 40 blocks, so 36 are missing? The dd actually succeeded, and did finish the job in about one day. The badblocks were found after about the first 7 Gigs. Is there no way like the conv=noerror for mdadm, to just continue? Can I restore the superblock on the .img file somehow? Is it probably save to --zero-superblock all the three disks and that the RAID array will create two new superblocks (Leaving the spare out, because its probably out of date). I can do the dd again, but I think it will do the same thing, because it finished 'succesfully'. The superblock is at the end of the disk I read, about the last 64-128K or something. My experience is that dd conv=noerror doesn't do the job correctly!! It still won't write a block that it cannot read. Please use dd_rescue -A /dev/hdd1 /mnt/hdb1/Faulty-RAIDDisk.img instead. See dd_rescue --help. ADEVICE /dev/hdb1 /dev/hdc1 /dev/loop0 ARRAY /dev/md0 devices=/dev/hdb1,/dev/hdc1,/dev/loop0 another thing: /mnt/hdb1/ is not the same hdb1, you are using in the raid5, is it? It might be a bad idea to mount /dev/hdb1, write to it, and afterwards assemble the array with hdb1 being part of it ... Extra bad, if loop0 points to a file on hdb1 ?? However, if you did dd to a file on the partition, that should be part of the degraded raid5 array, I guess your data is already gone ... Good luck Burkhard - 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: will mdadm work with a raid created using raidtools
On Wednesday February 15, [EMAIL PROTECTED] wrote: I may be a bit late in asking this because I already gave it a try but will mdadm work with a raid created using raidtools? Yes. There is no difference in the arrays created by raidtools or mdadm. 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: NVRAM support
On Wednesday February 15, [EMAIL PROTECTED] wrote: Hi, My intention was not to use a NVRAM device for swap. Enterprise storage systems use NVRAM for better data protection/faster recovery in case of a crash. Modern CPUs can do RAID calculation very fast. But Linux RAID is vulnerable when a crash during a write operation occurs. E.g. Data and parity write requests are issued in parallel but only one finishes. This will lead to inconsistent data. It will be undetected and can not be repaired. Right? Wrong. Well, maybe 5% right. If the array is degraded, that the inconsistency cannot be detected. If the array is fully functioning, then any inconsistency will be corrected by a 'resync'. How can journaling be implemented within linux-raid? With a fair bit of work. :-) I have seen a paper that tries this in cooperation with a file system: ?Journal-guided Resynchronization for Software RAID? www.cs.wisc.edu/adsl/Publications This is using the ext3 journal to make the 'resync' (mentioned above) faster. Write-intent bitmaps can achieve similar speedups with different costs. But I would rather see a solution within md so that other file systems or LVM can be used on top of md. Currently there is no solution to the crash while writing and degraded on restart means possible silent data corruption problem. However is it, in reality, a very small problem (unless you regularly run with a degraded array - don't do that). The only practical fix at the filesystem level is, as you suggest, journalling to NVRAM. There is work underway to restructure md/raid5 to be able to off-load the xor and raid6 calculations to dedicated hardware. This restructure would also make it a lot easier to journal raid5 updates thus closing this hole (and also improving write latency). 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: 2+ raid sets, sata and a missing hd question
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... regards, mark hahn. - 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
