Re: raid5 reshape/resync
Nagilum said: (by the date of Tue, 11 Dec 2007 22:56:13 +0100) Ok, I've recreated the problem in form of a semiautomatic testcase. All necessary files (plus the old xfs_repair output) are at: http://www.nagilum.de/md/ After running the test.sh the created xfs filesystem on the raid device is broken and (at last in my case) cannot be mounted anymore. I think that you should file a bugreport, and provide there the explanations you have put in there. An automated test case that leads to xfs corruption is a neat snack for bug squashers ;-) I wonder however where to report this - the xfs or raid ? Eventually cross report to both places and write in the bugreport that you are not sure on which side there is a bug. best regards -- Janek Kozicki | - 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: Please Help!!! Raid 5 reshape failed!
On Friday December 14, [EMAIL PROTECTED] wrote: gentoofs ~#mdadm --assemble /dev/md1 /dev/sdc /dev/sdd /dev/sdf mdadm: /dev/md1 assembled from 2 drives - not enough to start the array Try adding --run. or maybe --force. 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: [PATCH 007 of 7] md: Get name for block device in sysfs
On Saturday December 15, [EMAIL PROTECTED] wrote: On Dec 14, 2007 7:26 AM, NeilBrown [EMAIL PROTECTED] wrote: Given an fd on a block device, returns a string like /block/sda/sda1 which can be used to find related information in /sys. As pointed out to when you came up with the idea, we can't do this. A devpath is a path to the device and will not necessarily start with /block for block devices. It may start with /devices and can be much longer than BDEVNAME_SIZE*2 + 10. When you say will not necessarily can I take that to mean that it currently does, but it might (will) change?? In that case can we have the patch as it stands and when the path to block devices in /sys changes, the ioctl can be changed at the same time to match? Or are you saying that as the kernel is today, some block devices appear under /devices/..., in which case could you please give an example? Thanks, 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
