dm-loop and kernel 3.x

dm-loop and kernel 3.x

[Matt Coleman]

Hello,

I just tried (unsuccessfully) to apply the dm-loop patches to kernel 3.2.0. dm-bio-list-helpers.patch failed to apply because dm-bio-list.h no longer exists in the kernel tree. Is this an abandoned project, or were the changes incorporated into the kernel's existing loopback support? (...as hinted at here: http://www.redhat.com/archives/dm-devel/2012-February/msg00041.html)

Thanks,
Matt

Re: dm-loop and kernel 3.x

[Bryn M. Reeves]

On 08/08/2012 03:33 PM, Matt Coleman wrote:
> I just tried (unsuccessfully) to apply the dm-loop patches to kernel
> 3.2.0. dm-bio-list-helpers.patch failed to apply because
> dm-bio-list.h no longer exists in the kernel tree. Is this an
> abandoned project, or were the changes incorporated into the kernel's
> existing loopback support? (...as hinted at here:
> http://www.redhat.com/archives/dm-devel/2012-February/msg00041.html)

Most of the support patches went in to mainline several years ago so
this is probably due to later changes in md/ - I'd have to take a look
at the errors to see what's failing for you.

That said, the original patch is somewhat abandoned at this stage. I've
not done any work on it beyond helping folks get it applied and built
for quite a few years and the block mapping approach it uses was
rejected on LKML without VFS changes to make it safe (it operates behind
the file system's back).

I did start work last year on a revised dm-loop that was a refactoring
of and thin wrapper around the existing drivers/block loop driver but
this isn't published anywhere at the moment.

It could probably be cleaned up and put somewhere without too much work
but it's not something I'm working on regularly at the moment.

I know Mikulas was also interested in reviving dm-loop and we had some
discussions at Devconf in Brno earlier in the year but nothing has
happened since.

Regards,
Bryn.

Re: dm-loop and kernel 3.x

[Bryn M. Reeves]

On 08/08/2012 03:33 PM, Matt Coleman wrote:
> I just tried (unsuccessfully) to apply the dm-loop patches to kernel
> 3.2.0. dm-bio-list-helpers.patch failed to apply because

Out of interest, what features where you particularly interested in in
dm-loop today? The original motivation was performance and to break the
limit on the maximum number of loop devices (both of which are now
somewhat less of a problem for the main loop driver) so the main benefit
today seems to be to have loopback support as a native dm target
(avoiding the need for two block devices to use loop files).

Regards,
Bryn.

Re: dm-loop and kernel 3.x

[Matt Coleman]

On Aug 8, 2012, at 10:46 AM, Bryn M. Reeves <bmr@redhat.com> wrote:

> On 08/08/2012 03:33 PM, Matt Coleman wrote:
>> I just tried (unsuccessfully) to apply the dm-loop patches to kernel
>> 3.2.0. dm-bio-list-helpers.patch failed to apply because
> 
> Out of interest, what features where you particularly interested in in
> dm-loop today? The original motivation was performance and to break the
> limit on the maximum number of loop devices (both of which are now
> somewhat less of a problem for the main loop driver) so the main benefit
> today seems to be to have loopback support as a native dm target
> (avoiding the need for two block devices to use loop files).

I was looking to remove the limit on maximum number of loop devices. I wasn't aware that had changed. Was the limit entirely lifted, or is there a new higher limit? When did that change occur (which kernel version)?

Re: dm-loop and kernel 3.x

[Bryn M. Reeves]

On 08/08/2012 04:34 PM, Matt Coleman wrote:
> I was looking to remove the limit on maximum number of loop devices.
> I wasn't aware that had changed. Was the limit entirely lifted, or is
> there a new higher limit? When did that change occur (which kernel version)?

2007 - v2.6.21-3222-g7328508. Devices are now allocated dynamically as
required. The initial support was in this commit:

commit 73285082745045bcd64333c1fbaa88f8490f2626
Author: Ken Chen <kenchen@google.com>
Date:   Tue May 8 00:28:20 2007 -0700

  remove artificial software max_loop limit

  Remove artificial maximum 256 loop device that can be created due to a
  legacy device number limit.  Searching through lkml archive, there are
  several instances where users complained about the artificial limit
  that the loop driver impose.  There is no reason to have such limit.

  This patch rid the limit entirely and make loop device and associated
  block queue instantiation on demand.  With on-demand instantiation,
  it also gives the benefit of not wasting memory if these devices are
  not in use (compare to current implementation that always create 8
  loop devices), a net improvement in both areas.  This version is both
  tested with creation of large number of loop devices and is
  compatible with existing losetup/mount user land tools.

  There are a number of people who worked on this and provided valuable
  suggestions, in no particular order, by:

  Jens Axboe
  Jan Engelhardt
  Christoph Hellwig
  Thomas M

  Signed-off-by: Ken Chen <kenchen@google.com>
  Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>
  Cc: Christoph Hellwig <hch@lst.de>
  Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
  Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

There are several fixes that landed later (78f4bb3 and a1c15c5) that are
important if using partitionable loop devices. Those all went into
2.6.39 so any 3.x kernel should be a reasonable choice.

Regards,
Bryn.