But a "dumb" implementation means the fs doesn't know what the md layer is
doing to its reads and writes and can easily result in an inefficient
filesystem. What's really needed is a way for the fs and md layers to
communicate with each other by means of an API where the fs can "hint" that
it would like certain data to be stored near or separate from other data,
and can find out the underlying "stripe" size so it can lay out e.g.
cylinder groups or log blocks optimally. Also, it should be possible for
the fs to suggest different write behavior for log blocks, inodes, file
data, etc., so the md can schedule physical I/O better from both safety and
performance standpoints.
| Conceptually it seems simpler to have the virtual layer which understands
| how to span multiple partitions, but which looks like a block device from
| the "user" view, thus allowing any filesystem type to be used upon it, be
+--->8
Simpler, yes, but this hurts if the fs's concept of the location of a block
differs substantially from the md's concept.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH Kiss my bits, Billy-boy.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/