LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: maximum of 256 loop devices - not enough for cdrom server
@ 2007-01-25 17:38 devzero
0 siblings, 0 replies; 4+ messages in thread
From: devzero @ 2007-01-25 17:38 UTC (permalink / raw)
To: linux-kernel
Hi !
this thread was about maximum number of loopdevices being limited to 256.
actually, there is dm-loop.c under development, a device-mapper target to replace traditional loopdevice. see discussion on dm-devel mailinglist.
it`s still having issues and thus not being an option for now, but maybe worth keeping an eye on if you are in need of having more than 256 loop devices......
regards
roland
On Thu, 26 May 2005 22:14:38 +0200 Jose Luis Domingo Lopez wrote:
> On Thursday, 26 May 2005, at 03:06:34 +0200,
> roland wrote:
>
> > I want to build a cd-rom server and want to use the loop-driver (loop.c) for \
> > that.
> > That server will be HUGE and I will need to loopback mount more than 256 .iso \
> > images in the near future.
> > Unfortunately, the loop driver doesn`t support >256 device nodes.
> >
> > Is there a possible solution for this "problem" ?
First, let's understand the kernel version. 2.4.x or 2.6.y?
I'm only looking at 2.6.y.
Roland, have you tried increasing the max. value of max_loop yet?
> Beware: not a kernel hacker, not even a proficient programmer.
>
> It seems it would be easy, just changing the max current loop device
> number value (256) to something higher (i.e., 4096). Note, however, that
> loop devices are described by an array of structs statically allocated at
> module load time, so expect memory usage to grow linearly and search operations
> on the array become slower at least linearly.
The loop_device array is kmalloc-ed at load/init time.
On x86 (32-bit), struct loop_device is 336 bytes, and with kmalloc()
having an upper limit of 128 KB, the max. number of loop_devices that
can be allocated at one time is 128 * 1024 / 336 = 390, not a huge
improvement over 256 loopback devices.
I don't know of any reason that vmalloc() couldn't be used here
instead of kmalloc(), and once that hurdle is cleared (the 128 KB one),
since minor number on 2.6.y is 20 bits, there can be plenty of loopback
devices AFAIK.
I'm sure that Al or probably Andrew could answer this reliably.
> There is one thing that maybe would need some attetion: minor number
> allocation for loopback block devices. Now they are assigned at module
> initialization, but I don't know the current status in the Linux kernel
> with respect to (major,minor) sizes and allocation.
>
> Hope someone more knowledgeable jumps into this :-)
---
~Randy
http://www.madrone.org/donate/RFD1.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: maximum of 256 loop devices - not enough for cdrom server
2005-05-26 20:14 ` Jose Luis Domingo Lopez
@ 2005-06-04 1:14 ` randy_dunlap
0 siblings, 0 replies; 4+ messages in thread
From: randy_dunlap @ 2005-06-04 1:14 UTC (permalink / raw)
To: Jose Luis Domingo Lopez; +Cc: linux-kernel, for_spam
On Thu, 26 May 2005 22:14:38 +0200 Jose Luis Domingo Lopez wrote:
| On Thursday, 26 May 2005, at 03:06:34 +0200,
| roland wrote:
|
| > I want to build a cd-rom server and want to use the loop-driver (loop.c) for that.
| > That server will be HUGE and I will need to loopback mount more than 256 .iso images in the near future.
| > Unfortunately, the loop driver doesn`t support >256 device nodes.
| >
| > Is there a possible solution for this "problem" ?
First, let's understand the kernel version. 2.4.x or 2.6.y?
I'm only looking at 2.6.y.
Roland, have you tried increasing the max. value of max_loop yet?
| Beware: not a kernel hacker, not even a proficient programmer.
|
| It seems it would be easy, just changing the max current loop device
| number value (256) to something higher (i.e., 4096). Note, however, that
| loop devices are described by an array of structs statically allocated at
| module load time, so expect memory usage to grow linearly and search operations
| on the array become slower at least linearly.
The loop_device array is kmalloc-ed at load/init time.
On x86 (32-bit), struct loop_device is 336 bytes, and with kmalloc()
having an upper limit of 128 KB, the max. number of loop_devices that
can be allocated at one time is 128 * 1024 / 336 = 390, not a huge
improvement over 256 loopback devices.
I don't know of any reason that vmalloc() couldn't be used here
instead of kmalloc(), and once that hurdle is cleared (the 128 KB one),
since minor number on 2.6.y is 20 bits, there can be plenty of loopback
devices AFAIK.
I'm sure that Al or probably Andrew could answer this reliably.
| There is one thing that maybe would need some attetion: minor number
| allocation for loopback block devices. Now they are assigned at module
| initialization, but I don't know the current status in the Linux kernel
| with respect to (major,minor) sizes and allocation.
|
| Hope someone more knowledgeable jumps into this :-)
---
~Randy
http://www.madrone.org/donate/RFD1.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: maximum of 256 loop devices - not enough for cdrom server
2005-05-26 1:06 roland
@ 2005-05-26 20:14 ` Jose Luis Domingo Lopez
2005-06-04 1:14 ` randy_dunlap
0 siblings, 1 reply; 4+ messages in thread
From: Jose Luis Domingo Lopez @ 2005-05-26 20:14 UTC (permalink / raw)
To: linux-kernel; +Cc: roland
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
On Thursday, 26 May 2005, at 03:06:34 +0200,
roland wrote:
> Is there a possible solution for this "problem" ?
>
Beware: not a kernel hacker, not even a proficient programmer.
It seems it would be easy, just changing the max current loop device
number value (256) to something higher (i.e., 4096). Note, however, that
loop devices are described by an array of structs statically allocated at
module load time, so expect memory usage to grow linearly and search operations
on the array become slower at least linearly.
There is one thing that maybe would need some attetion: minor number
allocation for loopback block devices. Now they are assigned at module
initialization, but I don't know the current status in the Linux kernel
with respect to (major,minor) sizes and allocation.
Hope someone more knowledgeable jumps into this :-)
Greetings,
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.11.10)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* maximum of 256 loop devices - not enough for cdrom server
@ 2005-05-26 1:06 roland
2005-05-26 20:14 ` Jose Luis Domingo Lopez
0 siblings, 1 reply; 4+ messages in thread
From: roland @ 2005-05-26 1:06 UTC (permalink / raw)
To: linux-kernel
Hello !
I want to build a cd-rom server and want to use the loop-driver (loop.c) for that.
That server will be HUGE and I will need to loopback mount more than 256 .iso images in the near future.
Unfortunately, the loop driver doesn`t support >256 device nodes.
Is there a possible solution for this "problem" ?
regards
roland
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-01-25 17:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-25 17:38 maximum of 256 loop devices - not enough for cdrom server devzero
-- strict thread matches above, loose matches on Subject: below --
2005-05-26 1:06 roland
2005-05-26 20:14 ` Jose Luis Domingo Lopez
2005-06-04 1:14 ` randy_dunlap
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).