|| ||Kevin Corry <kevcorry-AT-us.ibm.com>|
|| ||Marcelo Tosatti <marcelo.tosatti-AT-cyclades.com>,
Joe Thornber <thornber-AT-sistina.com>|
|| ||Re: Device-mapper submission for 2.4|
|| ||Tue, 9 Dec 2003 11:45:04 -0600|
|| ||Linux Mailing List <linux-kernel-AT-vger.kernel.org>|
On Tuesday 09 December 2003 08:10, Marcelo Tosatti wrote:
> On Tue, 9 Dec 2003, Joe Thornber wrote:
> > On Tue, Dec 09, 2003 at 11:15:08AM -0200, Marcelo Tosatti wrote:
> > > I believe 2.6 is the right place for the device mapper.
> > So what's the difference between a new filesystem like XFS and a new
> > device driver like dm ?
> Expected question...
> XFS is a totally different filesystem from the ones present in 2.4.
> As far as I know, we already have the similar functionality in 2.4 with
> LVM. Device mapper provides the same functionality but in a much cleaner
> way. Is that right?
With all due respect, I don't really agree with this assessment.
To the casual observer, XFS is just another filesystem. It's used to manage
files, just like with ext3, Reiser, or JFS. However, XFS provides certain
features and performance characteristics that may not be found in the other
filesystems. For this reason, many people prefer XFS over the other
filesystems, and have pushed for its inclusion in the 2.4 kernel. Of course,
I'd argue that just as many (if not more) people have very little preference
as to which filesystem they use. They're happy as long as their data doesn't
get corrupted if their system crashes.
The situation with Device-Mapper is *very* similar. There are plenty of people
that are happy using LVM1, and probably don't care much about Device-Mapper
at this point. But there are also many people who prefer the improved
features offered by using Device-Mapper. The two new volume management tools,
LVM2 and EVMS, provide significant improvements over LVM1, such as improved
metadata formats, more reliable metadata updates, better user interfaces, in
addition to features that aren't available with LVM1, such as asynchronous
snapshots. Device-Mapper also provides a modular interface for adding new
functionality. For example, the EVMS project includes a module for performing
block-level bad-block-relocation, and another developer has contributed a
module for block-level encryption based on the crypto API. These new volume
management tools only work with Device-Mapper, because LVM1 simply doesn't
have the flexibility necessary to provide these capabilities. Again, this
situation seems to closely mirror the situation with XFS vs. the existing
Another compelling reason in my mind is that unlike the variety of filesystems
that exist both in 2.4 and in 2.6, LVM1 is no longer available in 2.6. Many
LVM1 users have been eager to try out 2.6 (and I certainly agree with you
that we need to convince more people to make this switch) but the fact that
their current tools are useless on 2.6 makes the transition far more painful.
It would be a huge benefit if these folks were able to first transition to
the new volume management tools while remaining on a 2.4 kernel. Then after
they're comfortable with this first switch, they can begin transitioning to a
2.6 kernel, where the new tools will work seemlessly.
I certainly understand your apprehension about accepting new drivers that
modify common kernel code. As with XFS, nearly all of the submitted code sits
in its own directory, and is only enabled if a user decides he needs it. And
the common changes really are incredibly minimal.
Joe's first patch changes all of 8 lines in the JBD code, which is done to
prevent JBD and Device-Mapper from stepping on each other's private data. The
second patch (mempool) only adds new functionality that won't affect any
existing code. (I'm actually suprised the mempool code hasn't been merged
yet, since it would be quite useful for any number of drivers and/or
filesystems besides Device-Mapper. It has certainly come in quite handy in
2.6.) And the changes in arch/ are simply to support the Device-Mapper
interface on 64-bit architectures.
I'd be happy to answer any questions or provide any other information that
would help you with this decision. If you'd like additional review of the
common code changes, I'll gladly look for volunteers to help with what should
be a very simple review.
I truly believe that including Device-Mapper will not only benefit users who
wish to continue on the 2.4 platform, but also those who are looking for an
easier path to migrate to 2.6.
Thanks very much for your time, Marcelo!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)