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
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,
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,
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
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
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 use:
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
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
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...
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
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 via
> webmailer.
>
>
> > -Ursprüngliche Nachricht-
> &
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?
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
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
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,
> >
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
You might want a more radical patch :
I agree that my patch is not the perfect solution for max_loop problem.
But it nearly doubles max_loop for me (using 386 arch) and moreover it
is a FIX for incorrect implementation in kernel IMHO. So I can see
REASON to include it in Kernel. Do I cry at
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
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 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
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
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
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
* 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?
* 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?
--
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
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 limitation.
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 all?
My
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 crap, it
oh - i forgot sending this to the list, since this was copypaste 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,
you`re completely right.
I
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
dynamically
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
You might want a more radical patch :
I agree that my patch is not the perfect solution for max_loop problem.
But it nearly doubles max_loop for me (using 386 arch) and moreover it
is a FIX for incorrect implementation in kernel IMHO. So I can see
REASON to include it in Kernel. Do I cry at
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
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,
instead of
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
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
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? Something
-
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 copypaste via
webmailer.
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
Gesendet: 22.03.07 14
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
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 (i = 0 ;
42 matches
Mail list logo
