o Rebuilds
> 90% kernel, AFAICS, otherwise you have races with requests that the driver is actively satisfying
o Auto-array enumeration
userspace
o Meta-data updates for "safe mode"
unsure of the definition of safe mode
o Array creation/deletion
of entire arrays? can mostly be done in userspace, but deletion also needs to update controller-wide metadata, which might be stored on active arrays.
o "Hot member addition"
userspace prepares, kernel completes
[moved this down in your list]
o Meta-data updates for topology changes (failed members, spare activation)
[warning: this is a tangent from the userspace sub-thread/topic]
the kernel, of course, must manage topology, otherwise things Don't Get Done, and requests don't do where they should. :)
Part of the value of device mapper is that it provides container objects for multi-disk groups, and a common method of messing around with those container objects. You clearly recognized the same need in emd... but I don't think we want two different pieces of code doing the same basic thing.
I do think that metadata management needs to be fairly cleanly separately (I like what emd did, there) such that a user needs three in-kernel pieces: * device mapper * generic raid1 engine * personality module
"personality" would be where the specifics of the metadata management lived, and it would be responsible for handling the specifics of non-hot-path events that nonetheless still need to be in the kernel.
- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
