Re: problem with software raid1 on 2.6.22.10: check/rebuild hangs
Am Montag, 3. Dezember 2007 04:00 schrieb Neil Brown: On Monday December 3, [EMAIL PROTECTED] wrote: Hello, with kernel 2.6.22.10 checking a raid1 or rebuilding ist does not work on one of our machines. After a short time the rebuild/check does not make progress any more . Processes which then access the filesystems on those raids are blocked. Nothing gets logged. Access to other filesystems works fine. If we boot 2.6.17.10 (the kernel we used befor upgrading to 2.6.22) the raids the check/rebuild is done without any problems. Sounds like a driver problem. Your symptoms are completely consistent with a request being submitted to the underlying device, and that request never completing. What controller runs your drives for you. You should probably report the problem to the relevant maintainer. 3ware Inc 9xxx-series SATA-RAID. There are no problems with normal operation. And when those raids stop to work all other disks on the same controller still work. And I don't see problems when reading from several disk in parallel. But this doesn't mean its not the driver, of course. Do you compile your own kernels? Yes. Would you be comfortable using git bisect to narrow down exactly which change breaks things? It should take more than a dozen or so tests. Yes. Its a little bit difficult as I can only test kernels in the night and on weekend. First I have to see how to use git to get the repository and how to do git bisect. NeilBrown Thanks and regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts - 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: raid6 check/repair
Dear Michael, Michael Schmitt wrote: Hi folks, Probably erroneously, you have sent this mail only to me, not to the list... I just want to give another suggestion. It may or may not be possible to repair inconsistent arrays but in either way some code there MUST at least warn the administrator that something (may) went wrong. Agreed. I don't know if linux-raid is the right code to implement this, but I think it is the most obvious place to implement it I guess. It's on the todo-list, I think, judging from this Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405919 Kind regards, Thiemo Nagel I thought this suggestion was once noted in this thread but I am not sure and I did not find it anymore, so please bare with me if I wrote it again. I had an issue once where the chipset / mainboard was broken so on one raid1 array I have diferent data was written to the disks occasionally and linux-raid / mdadm did not complain or do anything. Just by coincidence I found this issue that time. I did report this here on february too. - 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
mailing list configuration (was: raid6 check/repair)
Thiemo Nagel said: (by the date of Mon, 03 Dec 2007 20:59:21 +0100) Dear Michael, Michael Schmitt wrote: Hi folks, Probably erroneously, you have sent this mail only to me, not to the list... I have a similar problem all the time on this list. it would be really nice to reconfigure the mailing list server, so that reply does not reply to the sender but to the mailing list. Moreover, in sylpheed I have two reply options: reply to sender and reply to mailing list and both are using the *sender* address! I doubt that sylpheed is broken - it works on nearly 20 other lists, so I conclude that the server is seriously misconfigured. apologies for my stance. Anyone can comment on this? -- 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
