Hello,
I'm making a cd server with 300+ cd iso's, it is necessary to mount them all at the same time.
My problem is the following, namely the loop device only supports up to 256 loop devices.. Is it possible to increase this in any way in the loop module?
thanks in advance
re: more loopbacks
It's defined and restricted in /usr/src/linux/drivers/block/loop.c, but I don't know exactly why it's restricted, without more information i wouldn't change it.
Maybe you could do this with serval instances of usermode-linux in connection with a local nfs (or something else, don't know much about how to interact with UML)
Ciao,
anon coward
re: more loopbacks
You are correct that it is defined there. The reason it is restricted is because of kmalloc; you can only kmalloc up to 128K, and the structure that loop uses is ~350 bytes (if you wanted to find out for sure you could write a little kernel module). So 350bytes * 256 entries gives you 89600 bytes, and you can go up to a maximum of 131072. Basically, you could *possibly* increase the size, but I wouldn't count on it. The only real way to increase the size is to rewrite the loop kernel module to use vmalloc; however, I don't guarantee any results, this is just from a quick perusal around the code. If you are not comfortable playing around with rewriting the kernel modules (trust me, I certainly am not), I would suggest an alternate solution; maybe get a couple of other machines, loopback mount on them, and then NFS export them.
Thanks for the reply, I'am lo
Thanks for the reply, I'am looking for other solutions now, perhaps I'll give the vmalloc a try :).
Currently It's only a test system...
kernel isn't only problem
Check out /usr/include/sys/sysmacros.h. Even when you use vmalloc, e.g. using this patch:
http://lkml.org/lkml/2004/12/10/12
you still can't alloc more than 256 devices with the same major mode #.. since major mode is just left-shifted 8 bits to the top end of an unsigned int:
# define makedev(major, minor) ((((unsigned int) (major)) << 8)| ((unsigned int) (minor)))
Am I missing something, or isn't this a limit to the number of devices of a certain kind (same major mode) on a linux system?
Cheers,
Pablo
old header?
include/linux/kdev_t.h:
#define MINORBITS 20 ... static inline u32 new_encode_dev(dev_t dev) { unsigned major = MAJOR(dev); unsigned minor = MINOR(dev); return (minor & 0xff) | (major << 8) | ((minor & ~0xff) << 12); }It just depends on the filesystem on-disk format...
udev
The header is for devfs.. apparently udev (available in newer fedora core, others) supports 262142 minor number/devices.
So, that patch along with udev gives full support for the higher number of devices.
???
No, it's not. Just grep for the function calls in the source.
Even if it were, it was just cited as a irrefutable source of the kernel's current 12:20 major:minor split (with a funny encoding at the kernel-user binary interface to be 8:8-backwards compatible).
udev just takes these numbers out of /sys and creates matching device nodes in /dev, that has nothing to do with numbering or encoding, just copying numbers around in an intelligent way. The fs used for /dev still has to be able to store more than 8 minor bits, else udev will fail here.
Btw as everyone knows (remember the 20 address lines of the 8088 and the 1M addressable limit in real mode:) : (1 << 20) == 1M
FS support actually added IMHO
I think that the support has actually been added for holding minors >= 256. That depends on the filesystem, yes; however, remember that udev is configured (at least on my Gentoo) to use a virtual filesystem, like ramfs / tmpfs.
Links I found about this issue:
http://lwn.net/Articles/75928/
and from this I quote:
http://lwn.net/Articles/58199/
"Expanding dev_t to 64 bits is there, though the list acknowledges that the current 32-bit size will be enough for 2.6.0. Reaching 64 bits will require additional work with certain filesystems (such as older NFS protocols) which are not prepared for it."
I.e., it means that for 32 bit dev_t there is no problem.