Linus,
You have undoubtedly heard from many people their
opinions of some of the disputed design issues of
EVMS. I would very much like to hear what your
opinions are on the following points:
1) In-kernel vs user space discovery
Today, EVMS employs in-kernel discovery. Some
members of the kernel community has expressed
their desire to rip all existing kernel code for
discovery (of partitions, etc) and move this
support into user space.
Do you agree that having only user space
discovery is good idea? And if so, will this be
a requirement for 2.6?
2) Separate vol. mgmt. subsystems vs.
Integrating vol. mgmt into the block layer
Christoph's new proposal seems to be to
consolidate all vol. mgmt. into a new block
layer/device interface. In the long term, this
might be the right direction to go. However,
this does not seem likely to be completed in
the 2.5/2.6 timeframe. What will be used for
volume management until then?
Assuming compatible metadata formats, it seems
that MD, LVM, and EVMS as separate components
could be used until such a common infrastructure
was in place. At that point, the existing drivers
could be migrated to using the new infrastructure.
3) Generic access to intermediate (storage)
points that comprise a volume.
One of EVMS' original design goals was to
abstract internals of the composition of volumes
from the user and the block layer. There was
benefits in doing this, primarily in not wasting
some limited resources (ie. majors and minors),
as well as some memory. Each EVMS volume is
exported as a standard block device, but the
internal composition of that volume is considered
EVMS private data and not exposed directly to
the outside world. Thus member elements of a
volume are not accessible through the generic
block device operations.
Other (potential volume manager) implementation
have typically represented member elements as
independent block devices. Each being accessible
through the generic block device operations.
What's your opinion on the abstraction that EVMS
currently provides?
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:56 EST