[EMAIL PROTECTED] wrote:
On Fri, 06 Apr 2007 16:33:32 EDT, Bill Davidsen said:
Jan Engelhardt wrote:
Who cares if the user specifies max_loop=8 but still is able to open up
/dev/loop8, loop9, etc.? max_loop=X basically meant (at least to me)
"have at least X" loops ready.
On Fri, 06 Apr 2007 16:33:32 EDT, Bill Davidsen said:
> Jan Engelhardt wrote:
> > Who cares if the user specifies max_loop=8 but still is able to open up
> > /dev/loop8, loop9, etc.? max_loop=X basically meant (at least to me)
> > "have at least X" loops ready.
> >
> You have just come up with
Jan Engelhardt wrote:
On Apr 1 2007 11:10, Ken Chen wrote:
On 4/1/07, Tomas M <[EMAIL PROTECTED]> wrote:
I believe that IF you _really_ need to preserve the max_loop module
parameter, then the parameter should _not_ be ignored, rather it
should have the same function like before - to limit th
On Wed, 04 Apr 2007 12:31:25 +0200 Tomas M <[EMAIL PROTECTED]> wrote:
> > OK, here is a re-spin patch that I tested as module or
> > link-in-vmlinux. Both produce satisfactory result for me.
>
> Is there a plan to include this brilliant code in mainline Kernel?
> It works excellent, tested wit
he patch as an attachment just in case my email client
decide to eat away white spaces for the in-line text.
--
Subject: remove artificial software max_loop limit
From: "Ken Chen" <[EMAIL PROTECTED]>
Remove artificial maximum 256 l
On Apr 1 2007 11:10, Ken Chen wrote:
> On 4/1/07, Tomas M <[EMAIL PROTECTED]> wrote:
>
>> I believe that IF you _really_ need to preserve the max_loop module
>> parameter, then the parameter should _not_ be ignored, rather it
>> should have the same function like before - to limit the loop drive
On Sun, Apr 01, 2007 at 12:53:55PM +0200, [EMAIL PROTECTED] wrote:
> not sure if this is a real issue and if it`s UML or loop related -
> but how is low-memory situations being handled when creating loop
> devices ?
It's UML-related - it's not dealing with the case of a kernel thread
failing beca
<[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org
> Betreff: Re: [patch] remove artificial software max_loop limit
> On Apr 01, 2007, at 14:36:11, [EMAIL PROTECTED] wrote:
> >> Blame on the dual meaning of max_loop that it uses currently: to
> >> initialize a set of loop
On Apr 01, 2007, at 14:36:11, [EMAIL PROTECTED] wrote:
Blame on the dual meaning of max_loop that it uses currently: to
initialize a set of loop devices and as a side effect, it also sets
the upper limit. People are complaining about the former constrain,
isn't it? Does anyone uses the 2nd mean
>Blame on the dual meaning of max_loop that it uses currently: to
>initialize a set of loop devices and as a side effect, it also sets
>the upper limit. People are complaining about the former constrain,
>isn't it? Does anyone uses the 2nd meaning of upper limit?
>
>- Ken
what sense would it mak
On 4/1/07, Tomas M <[EMAIL PROTECTED]> wrote:
I believe that IF you _really_ need to preserve the max_loop module
parameter, then the parameter should _not_ be ignored, rather it should
have the same function like before - to limit the loop driver so if you
use max_loop=10 for example, it should
On 4/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
not sure if this is a real issue and if it`s UML or loop related -
but how is low-memory situations being handled when
creating loop devices ?
kernel returns -ENOMEM as an error code if there are no memory left to
initialize loop device.
I'm sorry I made a mistake,
there should be
module parameter
instead of
> boot parameter.
I am sorry.
The entire paragraph in my previous post should be the following:
I believe that IF you _really_ need to preserve the max_loop module
parameter, then the parameter should _not_ be ignored,
Andrew Morton wrote:
On Fri, 30 Mar 2007 02:25:37 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
-module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
So.. this change will cause a fatal error for anyone who is presently
using max_loop, won't it
> Von: [EMAIL PROTECTED]
> Gesendet: 01.04.07 11:16:14
> An: linux-kernel@vger.kernel.org
> Betreff: Re: [patch] remove artificial software max_loop limit
> >Remove artificial maximum 256 loop device that can be created due to a
> >legacy device number limit. Searching t
>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.
Hey, i was one
il client
decide to eat away white spaces for the in-line text.
--
Subject: remove artificial software max_loop limit
From: "Ken Chen" <[EMAIL PROTECTED]>
Remove artificial maximum 256 loop device that can be created due to a
leg
On Sat, 31 Mar 2007 10:07:43 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 30, 2007 at 02:15:24PM -0700, Andrew Morton wrote:
> > On Fri, 30 Mar 2007 02:25:37 -0700
> > "Ken Chen" <[EMAIL PROTECTED]> wrote:
> >
> > > -module_param(max_loop, int, 0);
> > > -MODULE_PARM_DESC(max_loop, "Max
On Fri, Mar 30, 2007 at 02:15:24PM -0700, Andrew Morton wrote:
> On Fri, 30 Mar 2007 02:25:37 -0700
> "Ken Chen" <[EMAIL PROTECTED]> wrote:
>
> > -module_param(max_loop, int, 0);
> > -MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
>
> So.. this change will cause a fatal er
On Fri, 30 Mar 2007 15:06:03 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
> On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > So.. this change will cause a fatal error for anyone who is presently
> > using max_loop, won't it? If they're doing that within their
> > initramfs/initrd/etc then
On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
So.. this change will cause a fatal error for anyone who is presently
using max_loop, won't it? If they're doing that within their
initramfs/initrd/etc then things could get rather ugly for them.
probably, if they access loop device non-seq
On Mar 30 2007 14:46, Andrew Morton wrote:
>
>ahem.
>
>On Fri, 30 Mar 2007 02:25:37 -0700
>"Ken Chen" <[EMAIL PROTECTED]> wrote:
>
>> +static DEFINE_MUTEX(loop_devices_mutex);
>> ...
>> +mutex_lock(&loop_device_mutex);
>
>which makes me suspect that you didn't send the patch which you meant to
ahem.
On Fri, 30 Mar 2007 02:25:37 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
> +static DEFINE_MUTEX(loop_devices_mutex);
> ...
> + mutex_lock(&loop_device_mutex);
which makes me suspect that you didn't send the patch which you meant to
send, so I'll drop it.
-
To unsubscribe from this li
On Fri, 30 Mar 2007 02:25:37 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
> -module_param(max_loop, int, 0);
> -MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
So.. this change will cause a fatal error for anyone who is presently
using max_loop, won't it? If they're doing t
On Mar 30 2007 02:25, Ken Chen wrote:
>
> Oh, crap. Google mail is innocent. It was me who did some ugly
> copy-paste between apps.
Well, you did it again :p
> I don't mind either way, this thing won't be bigger than 1^20 anyway.
> Oh, which reminds me that we probably should explicitly test a
On 3/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> lo->lo_device = NULL;
> lo->lo_backing_file = NULL;
> lo->lo_flags = 0;
> - set_capacity(disks[lo->lo_number], 0);
> + set_capacity(lo->lo_disk, 0);
> invalidate_bdev(bdev, 0);
> bd_set_size(bdev, 0);
> mapping_set_gfp_mask(mapping,
On Mar 30 2007 01:48, Ken Chen wrote:
> On 3/30/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> @@ -812,7 +811,7 @@ static int loop_set_fd
> lo->lo_queue->queuedata = lo;
> lo->lo_queue->unplug_fn = loop_unplug;
>
> - set_capacity(disks[lo->lo_number], size);
> + set_capacity(lo->lo_disk, size)
On 3/30/07, Ken Chen <[EMAIL PROTECTED]> wrote:
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
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
roland wrote:
partitions on loop or device-mapper devices ?
you can use kpartx tool for this.
bryn m. reeves told me, that it's probably poissible to create udev
rules that will automatically create partition maps when a new loop
device is setup, which is better than adding partitioning logig
Tomas M wrote:
255 loop devices are insufficient? What kind of scenario do you have
in mind?
Thank you very much for replying.
In 1981, Bill Gates said that 64KB of memory is enough for everybody.
And you know how much RAM do you have right now. :)
Actually, I believe the number was 640k, t
This is a diff from Ken Chen, who sent it to me a week ago and received
the claimed prize $256. I think it's partially based on Jan's code,
while if fixes the bug Jan mentioned (as far as I know).
It does the following:
- allocate loop dynamically on the fly
- allocate one more (spare) loop eac
On Mar 25 2007 10:40, Tomas M wrote:
>On ??, Jan Engelhardt wrote:
>
>> here's one. Allocates all the fluff dynamically. It does not
>> create any dev nodes by itself, so you need to do it (à la mdadm)
>
> I'm afraid that this would break a lot of things, for example mount
> -o loop will not work
On Mar 23, 2007, at 19:26:34, Jan Engelhardt wrote:
here's one. Allocates all the fluff dynamically. It does not create
any dev nodes by itself, so you need to do it (à la mdadm), but
you'll get all 1048576 available minors.
+static LIST_HEAD(loop_devices);
Maybe an rbtree would work bette
On Sun, Mar 25, 2007 at 10:40:10AM +0200, Tomas M wrote:
> >here's one. Allocates all the fluff dynamically. It does not create any
> >dev nodes by itself, so you need to do it (à la mdadm)
>
> I'm afraid that this would break a lot of things, for example mount -o
> loop will not work anymore unl
On Thu, Mar 22, 2007 at 04:09:13PM +, Pádraig Brady wrote:
> William Lee Irwin III wrote:
> > Any chance we can get some kind of devices set up for partitions of
> > loop devices if we're going to redo loopdev setup? That's been a thorn
> > in my side for some time.
>
> This script might be of
here's one. Allocates all the fluff dynamically. It does not create any
dev nodes by itself, so you need to do it (à la mdadm)
I'm afraid that this would break a lot of things, for example mount -o
loop will not work anymore unless you create /dev/loop* manually first,
am I correct? In this ca
On 3/23/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
@@ -1383,7 +1380,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = &loop_dev[0]; lo < &loop_dev[max_loop]; lo++) {
+ list_for_each_entry(lo, &loop_devices, lo_list) {
mutex_lo
On 3/23/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
Sadly, it locks up the foreground process (losetup that would be), and I
have not yet figured out why. And the mpt regression elsewhere is
hindering me in finding out faster.
You need to tell the block layer that each loop device is a whole
Hi,
here's one. Allocates all the fluff dynamically. It does not create any
dev nodes by itself, so you need to do it (à la mdadm), but you'll get all
1048576 available minors.
Sadly, it locks up the foreground process (losetup that would be), and I
have not yet figured out why. And the mpt regr
wondering that here are 13 postings about loopdevice limitation, but
nobody giving any comment about dm-loop (
http://sources.redhat.com/lvm2/wiki/DMLoop ), which is a solution for
this problem ..
If I understand it correctly, I would need 'dm' in kernel (or module)
and moreover I would nee
On Mar 22 2007 14:42, Eric Dumazet wrote:
>Instead of using :
>
>static struct loop_device *loop_dev;
>loop_dev = kmalloc(max_loop * sizeof(struct loop_device));
>
>Switch to :
>
>static struct loop_device **loop_dev;
>loop_dev = kmalloc(max_loop * sizeof(void *));
>if (!loop_dev) rollback...
>for
partitions on loop or device-mapper devices ?
you can use kpartx tool for this.
bryn m. reeves told me, that it's probably poissible to create udev rules
that will automatically create partition maps when a new loop device is
setup, which is better than adding partitioning logig into dm-loop f
che Nachricht-
> Von: [EMAIL PROTECTED]
> Gesendet: 22.03.07 14:53:19
> An: linux-kernel@vger.kernel.org
> Betreff: Re: max_loop limit
> oh - i forgot sending this to the list, since this was copy&paste via
> webmailer.
>
>
> > -Ursprüngliche Nac
On Thu, Mar 22, 2007 at 02:33:14PM +, Al Viro wrote:
> Correction: current ABI is crap. To set the thing up you need to open
> it and issue an ioctl. Which is a bloody bad idea, for obvious reasons...
Agreed. What would be a right way? Global device ala ptmx/tun/tap?
New syscall? Somethin
William Lee Irwin III wrote:
> Any chance we can get some kind of devices set up for partitions of
> loop devices if we're going to redo loopdev setup? That's been a thorn
> in my side for some time.
This script might be of use:
http://www.pixelbeat.org/scripts/lomount.sh
cheers,
Pádraig.
-
To un
Really, I dont think Tomas has the skill or time to follow a typical
lkml discussion.
Well I have the skills to follow LKML discussion, but I don't have the
skills to provide *perfect* patch for loop.c
So I'm offering a financial reward for the *perfect* loop.c patch.
It should support *A LO
On Thu, 2007-03-22 at 07:11 -0700, William Lee Irwin III wrote:
> On Thu, Mar 22 2007, Eric Dumazet wrote:
> >> Sure, but it's the first Tomas patch :)
>
> On Thu, Mar 22, 2007 at 02:54:57PM +0100, Jens Axboe wrote:
> > The more the reason to guide him in the direction of a right solution,
> > ins
On Thu, Mar 22, 2007 at 02:42:31PM +0100, Jens Axboe wrote:
> But this still wastes memory, why not just allocate each loop device
> dynamically when it is set up? The current approach is crap, it is just
> wasting memory for loop devices, queues, etc.
Correction: current ABI is crap. To set the
the correct tomb? :)
Instead of using :
::
Switch to :
::
I'm not any professional kernel hacker, so I don't understand the
mysteries regarding ** (pointers to pointers?). Is there anyone who
could provide CLEAN patch for loop.c, which would raise the max_loop
limit to (at least
On Thu, Mar 22 2007, Eric Dumazet wrote:
>> Sure, but it's the first Tomas patch :)
On Thu, Mar 22, 2007 at 02:54:57PM +0100, Jens Axboe wrote:
> The more the reason to guide him in the direction of a right solution,
> instead of extending the current bad one!
On Thu, Mar 22 2007, Eric Dumazet wr
On Thu, Mar 22 2007, Eric Dumazet wrote:
> On Thu, 22 Mar 2007 14:42:31 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
>
> > > This time, you would be limited to 16384 loop devices on x86_64, 32768 on
> > > i386 :)
> >
> > But this still wastes memory, why not just allocate each loop device
>
oh - i forgot sending this to the list, since this was copy&paste via
webmailer.
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> Gesendet: 22.03.07 14:42:45
> An: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> Betreff: Re: max_loop limit
> Hi Tomas
On Thu, 22 Mar 2007 14:42:31 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
> > This time, you would be limited to 16384 loop devices on x86_64, 32768 on
> > i386 :)
>
> But this still wastes memory, why not just allocate each loop device
> dynamically when it is set up? The current approach is cr
On Thu, Mar 22 2007, Eric Dumazet wrote:
> On Thu, 22 Mar 2007 12:37:54 +0100
> Tomas M <[EMAIL PROTECTED]> wrote:
>
> > The question is not "Why do we need more than 255 loops?".
> > The question should be "Why do we need the hardcoded 255-limit in kernel
> > while there is no reason for it at a
On Thu, 22 Mar 2007 12:37:54 +0100
Tomas M <[EMAIL PROTECTED]> wrote:
> The question is not "Why do we need more than 255 loops?".
> The question should be "Why do we need the hardcoded 255-limit in kernel
> while there is no reason for it at all?"
>
> My patch simply removes the hardcoded limit
255 loop devices are insufficient? What kind of scenario do you have
in mind?
Thank you very much for replying.
In 1981, Bill Gates said that 64KB of memory is enough for everybody.
And you know how much RAM do you have right now. :)
Every limit is bad. The limit of 255 loop devices has been
* Tomas M <[EMAIL PROTECTED]> wrote:
> I hope you will like it and you will include it in kernel.
> Or, if not, maybe this patch will start some debate regarding
> the current insufficient limit of 255 loop devices.
255 loop devices are insufficient? What kind of scenario do you have
in mind?
-
Hello,
this is my first code submitted to kernel, I hope you won't hate it.
This 4-lines-change patch adds support for nearly two-times more loop
devices. Explanation follows:
The maximum amount of loop devices has been 255 for many years, while
there is a lot of space for more. The maximum dep
59 matches
Mail list logo
