From: "Bryn M. Reeves" <bmr@redhat.com>
To: Matt Coleman <mcoleman@dattobackup.com>
Cc: device-mapper development <dm-devel@redhat.com>, breeves@redhat.com
Subject: Re: dm-loop and kernel 3.x
Date: Wed, 08 Aug 2012 17:00:00 +0100 [thread overview]
Message-ID: <50228D00.1020209@redhat.com> (raw)
In-Reply-To: <A8EC03E5-16E1-439E-8283-3740CBF2080C@dattobackup.com>
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.
prev parent reply other threads:[~2012-08-08 16:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 14:33 dm-loop and kernel 3.x Matt Coleman
2012-08-08 14:42 ` Bryn M. Reeves
2012-08-08 14:46 ` Bryn M. Reeves
2012-08-08 15:34 ` Matt Coleman
2012-08-08 16:00 ` Bryn M. Reeves [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50228D00.1020209@redhat.com \
--to=bmr@redhat.com \
--cc=breeves@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mcoleman@dattobackup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).