On 4/16/06, Neil Brown <[EMAIL PROTECTED]> wrote: > On Thursday April 13, [EMAIL PROTECTED] wrote: > > On 4/12/06, Neil Brown <[EMAIL PROTECTED]> wrote: > > > > > One thing that is on my todo list is supporting shared raid1, so that > > > several nodes in the cluster can assemble the same raid1 and access it > > > - providing that the clients all do proper mutual exclusion as > > > e.g. OCFS does. > > > > Very cool... that would be extremely nice to have. Any estimate on > > when you might get to this? > > > > I'm working on it, but there are lots of distractions.... > > The first step is getting support into the kernel for various > operations like suspending and resuming IO and resync. > That is progressing nicely.
Sounds good... will it be possible to suspend/resume IO to only specific members of the raid1 (aka partial IO/resync suspend/resume)? If not I have a tangential raid1 suspend/resume question: is there a better/cleaner way to suspend and resume a raid1 mirror than removing and re-adding a member? That is you: 1) establish a 2 disk raid1 2) suspend the mirror but allow degraded changes to occur (remove member?) 3) after a user specified interval resume the mirror to resync (re-add member?) 4) goto 2 Using the write-intent bitmap the resync should be relatively cheap. However, would it be better to just use mdadm to tag a member as write-mostly and enable write-behind on the raid1? BUT is there a way to set the write-behind to 0 to force a resync at a certain time (it would appear write-behind is a create-time feature)? thanks, mike - 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
