On Dec 31, 2007 1:05 PM, Neil Brown <[EMAIL PROTECTED]> wrote: > On Monday December 31, [EMAIL PROTECTED] wrote: > > > > I'm hoping that if I can get raid5 to continue despite the errors, I > > can bring back up enough of the server to continue, a bit like the > > remount-ro option in ext2/ext3. > > > > If not, oh well... > > Sorry, but it is "oh well". > > I could probably make it behave a bit better in this situation, but > not in time for you.
Understood, thanks much for the answer, I'll work on moving services to another server now. If that's a reasonable RFE for the people concerned, it'd be nice to have a non default md raidtab option, or an assemble option that says "continue as long as you can if kicking another drive will disable the array", I'd still be ok with the array staying read-write if block errors are passed through since the underlying filesystem would remount read only by itself. I think it my case, it would have allowed me to reboot my system with md5 damaged, limping on one drive fewer, having the lvm be read-write, and the /usr partition within it be read-only while /var within the same raid5 md, same LVM VG but different LV, could stay read-write. That might be a bit too much of wishful thinking though. Even having everything still run as read-only (again, as a non default option), would be nice. No idea how hard or unrealistic that is, but just throwing the idea out :) Either way, have a great new year. Best, Marc - 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
