On 12/08/2013 09:47 PM, Carl Hartung wrote:
Hi David,
Wouldn't the safest course of action be to clone these partitions and make backups of the others before proceeding? If the additional event on sdb5 was a read/write error causing the read only bit to be set, that could explain mdadm being 'cranky' about mounting and using the partition. That would also explain you being able to mount the partition manually in read only mode.
Along the same lines, are these drives SMART capable? Have you tried using smartctl to check on the status of sdb? Of particular interest would be the number of reallocated sectors and whether or not that number is perceptibly climbing -- in which case drive failure could be imminent.
I wish you the best of luck & regards,
Carl
Thanks Carl, Yes, I am going to copy the partition as a backup. I was able to rsync all the important data off the drive when I mounted them individually in the Recovery console. Given that this is 11.0, the data is all that is important, that being the configs, /var/spool, mysql tables, and web data. That is all safe. Now it is more "what happened?" As JA and the folks on the mdraid list think it is probably the old version of mdadm not handling the error right. We shall see. mdraid really isn't magic. It either works or it doesn't, if it doesn't, then there is either a glaring reason seen using --examine or --detail or it is just a bug with mdadm. Most everything is handled automatically after you issue --assemble, there are not a lot of user screw-ups you can make :-) (that's a good thing) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org