raid5.h documentation
Neil hello. you say raid5.h: ... * Whenever the delayed queue is empty and the device is not plugged, we * move any strips from delayed to handle and clear the DELAYED flag and set PREREAD_ACTIVE. ... i do not understand how can one move from delayed if delayed is empty . thank you -- Raz - 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: which disk the the one that data is on?
On 2006-07-19 at 08:33:21, Shai wrote: Another question on this matter please: If there is a raid5 with 4 disks and 1 missing, and we add that disk, while its doing the resync of that disk, how do we know which disk it is (if we forgot what one we added)? Everything is already in the /proc/mdstat (and mdadm -Q -D /dev/md0) output you posted: md0 : active raid5 hdd1[1] hdc1[0] hdh1[5](S) hdg1[4] hdf1[3] hde1[2] 781433344 blocks level 5, 64k chunk, algorithm 2 [5/5] [U] [=...] resync = 5.1% (9965184/195358336) finish=180.5min speed=17110K/sec There's a number after each component (hdc1[0]), and there's an U in the next line for each component. If some of the component drives are not there, or resyncing, something else will be there. You can also see that hdh1 is a (S)pare right now. [_] would mean that the component 0 is not (U)p to date. Make yourself familiar with this output so you are not confused should there be any problem. Similarly, mdadm output is containing largely the same information, but in a different layout, maybe that's more clear in some cases. Janos - 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
Is it possible to recover data after resync?
Situation: I accidentally killed the power to my 5-disk RAID 5 array. I then powered it back up and rebooted the system. After reboot, however, I got the follow- ing error when trying to assemble the array: mdadm -A -amd /dev/md0 /dev/sd[a-e] mdadm: /dev/md0 assembled from 2 drives - not enough to start the array. I had read somewhere that it's possible to recover an array using the -C option to mdadm. Unfortunately, I didn't specify 'missing', so instead of recovering, it's resyncing. Is there any way to recover the original data? I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: XFS and write barrier
On Wednesday July 19, [EMAIL PROTECTED] wrote: On Tue, Jul 18, 2006 at 06:58:56PM +1000, Neil Brown wrote: On Tuesday July 18, [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 01:32:38AM +0800, Federico Sevilla III wrote: On Sat, Jul 15, 2006 at 12:48:56PM +0200, Martin Steigerwald wrote: I am currently gathering information to write an article about journal filesystems with emphasis on write barrier functionality, how it works, why journalling filesystems need write barrier and the current implementation of write barrier support for different filesystems. Journalling filesystems need write barrier isn't really accurate. They can make good use of write barrier if it is supported, and where it isn't supported, they should use blkdev_issue_flush in combination with regular submit/wait. blkdev_issue_flush() causes a write cache flush - just like a barrier typically causes a write cache flush up to the I/O with the barrier in it. Both of these mechanisms provide the same thing - an I/O barrier that enforces ordering of I/Os to disk. Given that filesystems already indicate to the block layer when they want a barrier, wouldn't it be better to get the block layer to issue this cache flush if the underlying device doesn't support barriers and it receives a barrier request? A barrier means a lot more than just a flush. It means wait for all proceeding requests to commit flush write this request flush Any block device that uses the io scheduler could probably manage this. Other block devices might not find it so easy. Any particular reason for not supporting barriers on the other types of RAID? Imagine trying to implement barriers for raid0 (or any level with striping). You would need to block new requests wait for all requests to all devices to complete issue a flush to all devices issue the barrier request to the target device issue a flush to the target device permit new requests. This means raid0 would need to keep track of all pending requests, which it doesn't do. As the filesystem does, it is just as efficient to let the filesystem to the work. I guess raid0 could - block new requests - submit a no-op barrier to all devices - wait for the no-op to complete - submit the write/barrier request - permit new requests. This would avoid needing to keep track of all requests. However I don't think the Linux block layer supports a no-op barrer, and I don't think this would actually be better than not supporting barriers. The real value of barriers (as far as I can see) is that the target device can understand them so you don't need to stall the queue of requests flying over the buss to the device. If you need to stall the flow of requests and wait at the OS level, then the value of barriers disappears and you may as well wait in the filesystem code. At least, that is my understanding. I am happy to be educated. 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: raid5.h documentation
On Wednesday July 19, [EMAIL PROTECTED] wrote: Neil hello. you say raid5.h: ... * Whenever the delayed queue is empty and the device is not plugged, we * move any strips from delayed to handle and clear the DELAYED flag and set PREREAD_ACTIVE. ... i do not understand how can one move from delayed if delayed is empty . It should say Whenever the 'handle' queue is empty. 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: which disk the the one that data is on?
On Wednesday July 19, [EMAIL PROTECTED] wrote: Hi, Another question on this matter please: If there is a raid5 with 4 disks and 1 missing, and we add that disk, while its doing the resync of that disk, how do we know which disk it is (if we forgot what one we added)? mdadm --detail will list all the devices. The one that is being recovered won't be 'sync' - the others will. 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: md reports: unknown partition table - fixed.
On Tuesday July 18, [EMAIL PROTECTED] wrote: I think there's a bug here somewhere. I wonder/suspect that the superblock should contain the fact that it's a partitioned/able md device? I've thought about that and am not in favour. I would rather just assume everything is partitionable - put CREATE auto=part in mdadm.conf If this causes problems, then those problems need to be identified and fixed. 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: Is it possible to recover data after resync?
On Wednesday July 19, [EMAIL PROTECTED] wrote: Situation: I accidentally killed the power to my 5-disk RAID 5 array. I then powered it back up and rebooted the system. After reboot, however, I got the follow- ing error when trying to assemble the array: mdadm -A -amd /dev/md0 /dev/sd[a-e] mdadm: /dev/md0 assembled from 2 drives - not enough to start the array. I had read somewhere that it's possible to recover an array using the -C option to mdadm. Unfortunately, I didn't specify 'missing', so instead of recovering, it's resyncing. --assemble --force is worth try first and is much safer. Is there any way to recover the original data? Well, if you got all the right devices in the right order, then your data should be fine. If not, I hope you have good backups, because they are your only hope. 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: Is it possible to recover data after resync?
--- Neil Brown [EMAIL PROTECTED] wrote: On Wednesday July 19, [EMAIL PROTECTED] wrote: Situation: I accidentally killed the power to my 5-disk RAID 5 array. I then powered it back up and rebooted the system. After reboot, however, I got the follow- ing error when trying to assemble the array: mdadm -A -amd /dev/md0 /dev/sd[a-e] mdadm: /dev/md0 assembled from 2 drives - not enough to start the array. I had read somewhere that it's possible to recover an array using the -C option to mdadm. Unfortunately, I didn't specify 'missing', so instead of recovering, it's resyncing. --assemble --force is worth try first and is much safer. Is there any way to recover the original data? Well, if you got all the right devices in the right order, then your data should be fine. If not, I hope you have good backups, because they are your only hope. NeilBrown So do I just keep doing mdadm -A /dev/md0 /dev/ using different permutations of the devices until my data shows up? I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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 it possible to recover data after resync?
On Wednesday July 19, [EMAIL PROTECTED] wrote: Is there any way to recover the original data? Well, if you got all the right devices in the right order, then your data should be fine. If not, I hope you have good backups, because they are your only hope. NeilBrown So do I just keep doing mdadm -A /dev/md0 /dev/ using different permutations of the devices until my data shows up? Hard to say without precise details. Maybe it's worth a try, maybe not. 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: Is it possible to recover data after resync?
--- Neil Brown [EMAIL PROTECTED] wrote: On Wednesday July 19, [EMAIL PROTECTED] wrote: Is there any way to recover the original data? Well, if you got all the right devices in the right order, then your data should be fine. If not, I hope you have good backups, because they are your only hope. NeilBrown So do I just keep doing mdadm -A /dev/md0 /dev/ using different permutations of the devices until my data shows up? Hard to say without precise details. Maybe it's worth a try, maybe not. What details are needed? NeilBrown I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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 it possible to recover data after resync?
--- Neil Brown [EMAIL PROTECTED] wrote: On Wednesday July 19, [EMAIL PROTECTED] wrote: Is there any way to recover the original data? Well, if you got all the right devices in the right order, then your data should be fine. If not, I hope you have good backups, because they are your only hope. NeilBrown So do I just keep doing mdadm -A /dev/md0 /dev/ using different permutations of the devices until my data shows up? Hard to say without precise details. Maybe it's worth a try, maybe not. Ignore my previous message. Typing mdadm -C -amd -l5 -n5 -c128 /dev/md0 /dev/sde /dev/sdd /dev/sdc /dev/sdb missing seems to have done the trick. I'll do an add of /dev/sda and an fsck and report my results later. NeilBrown I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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
