Re: "Enhanced" MD code avaible for review
From: Jeff Garzik
Date: Sat Mar 27 2004 - 19:34:10 EST
Justin T. Gibbs wrote:
> 90% kernel, AFAICS, otherwise you have races with
requests that the driver is actively satisfying
o Auto-array enumeration
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/