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
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
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
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 th
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?
-
21 matches
Mail list logo
