[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
> 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 with 15000 loop devices, it's simply cool.
Thank you for your consideration.
Tomas
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
On 3/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yes, the distros do, and they recommend it to their users a lot.
Thanks. In that case I think we should retain the max_loop module parameter
for now.
Ken, when you respin that patch could you restore max_loop, and make its
use trigger a wa
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
28 matches
Mail list logo
