Re: "Enhanced" MD code avaible for review

From: Jeff Garzik
Date: Sat Mar 27 2004 - 19:34:10 EST


Justin T. Gibbs wrote:
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/