Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: fladd on September 14, 2009, 10:03:14 AM
-
Hi there,
what is the max of loop devices (to mount tcz extensions) wihtout specifying the grub parameter?
Also, I can imagine a system becoming so complex that it has tio exceed the 255 loop devices. What happens then? Isn't this a serious general limitation of the concept (as much as I like the modular idea)?
Regards,
fladd
-
There was a page on the Slax site about the limit of 256 max loops being done away with in kernel 2.6.24. It seems to say you can boot with max_loop=500 and you would have 500 loops available. I have ran out of loops with my max_loop=255, and I will see what happens if I set it higher and keep adding extnesions.
I saw that page in the early days of TC but we didn't have enough extensions to test it with at the time.
-
In the future, it may be beneficial / necessary to combine extensions which are normally used together into larger extensions, reducing the number.
-
You don't have to mount everything. You can selectively load into ram.
-
You don't have to mount everything. You can selectively load into ram.
Well, not with only 128MB, though. The ability to just mount it and save RAM is a great thing. So the kernel standard now is 256 and that can be extended up to 500?
fladd
-
Slax claims it sponsored code that supports unlimited loop devices by simply using the max_loop boot parameter and it was added to 2.6.24 and later.
http://www.slax.org/documentation_loop_mount.php
-
I tried approaches using the instructions listed in the above link to make use of more than 255 loop devices, to no avail. I looked in loop.c in the 2.6.29.1 kernel and the last commit to that file was in 2005. So we seem to be stuck with a 255 limit on the number of tczs we can mount. I read the threads where the patch was being discussed, but it evidently was not included.
Of course, correct me if I am wrong.
-
Mmh, too bad. That might introduce a serious problem.
fladd
-
Mmh, too bad. That might introduce a serious problem.
Don't think soo.
1) We can investigate it a bit more, I mean SLAX and Kernel patch
2) You can combine extensions on a logical way to reduce number of loops.
-
Though I can't find where the patch was applied, and cant get more than 256 loop mounts, there is a chance I am missing something. I will review my steps and make sure something was not overlooked.
Right now I am mounting my tcz's by mounting the loop device instead of the tcz file, but still run into the 256 maximum, or the default maximum when not using max_loop parameter. My tce directory has about 270 tcz extensions right now. This is by no means on the front burner but I am curious about the loop limit and will keep my eye on what happens with it.
-
TC 1.x will let you specify max_loop=700 and 700 devices get created. TC 2.x will only let you specify 256 or no extras get created if you try to go higher and you will max out at the standard default. I am now posting with 485 tcz extensions mounted. Rather the same set of extensions copied to different directories and mounted in different places. There is evidently a change in the kernel since 2.6.26. So , and you don't even have to issue a different mount command once you get past 256 loops. I am going to poke around and see what has changed.
-
If you peruse the comments of linux-2.6.29.1-tinycore/drivers/block/loop.c you will see:
*
* Maximum number of loop devices when compiled-in now selectable by passing
* max_loop=<1-255> to the kernel on boot.
* Erik I. Bolsø, <eriki@himolde.no>, Oct 31, 1999
*
* Completely rewrite request handling to be make_request_fn style and
* non blocking, pushing work to a helper thread. Lots of fixes from
* Al Viro too.
* Jens Axboe <axboe@suse.de>, Nov 2000
*
* Support up to 256 loop devices
* Heinz Mauelshagen <mge@sistina.com>, Feb 2002
*
-
True, but 2.6.26 says the same thing but is able to create with max_loop more than 256 loop devices and mount them.
-
Hi there,
what is the max of loop devices (to mount tcz extensions) wihtout specifying the grub parameter?
Also, I can imagine a system becoming so complex that it has tio exceed the 255 loop devices. What happens then? Isn't this a serious general limitation of the concept (as much as I like the modular idea)?
Regards,
fladd
On the other hand won't an excessive number of loop devices adversely affect performance?
I wonder how long it takes to boot 256 extensions?
-
Each mounted loop device takes a few bytes of ram. Mounted tcz's naturally show a small performance difference from having everything in RAM due to the gzip decompression as well as the speed of the device the tcz resides on.
On an 800mhz box, mounting 250 tczs adds about 20 seconds to the boot process. Not exactly unlivable for a booting a pretty full sized system.
-
Given the architecture, a mount is going to be faster than untarring an archive to ram.
Even when remastered in, loading 255 extensions that were cpio'ed into ram, would be slower than mounting them at boot time.
Given that the first user to hit an out-of-loops bug in tce-load (fixed in 2.4) was at 100, lets not make a mountain out of a mole hill.
And, let's not forget that just because tcz is going to be the extension type moving forward does not imply that they must be mounted.
I would however, add the max_loop=255 to my boot loader.
-
what is the max of loop devices (to mount tcz extensions) wihtout specifying the grub parameter?
By default 2.3 has 80 loop devices available only.
-
It seems the 256 limit was done away with before 2.6.26 and for some reason added back in before 2.6.29.1, discreetly noted somewhere in change-log land but not in the loop.c file itself. Perhaps there are other kernel functions that were affected by having more than 256 mounted loops.
With 655 tcz extensions in the repo, and the fact that I never copy to ram since I don't have a lot of it, I actually hit the 256 limit with normal use of TC as a desktop distro when I installed the things I would normally install (along with their dev extensions) when they are available. So personally I thought it worthwhile to see if loops past 256 could be mounted, using the instructions given on the Slax page if losetup did not otherwise cooperate.
The 256 limit has evidently been reinstated in the kernel and not an issue of boot parameters, mounting procedure, device node issues, or other things in our control. But sure, it is a limit that can be lived within and the kernel is usually good about raising the ceiling on max filesystem size, max RAM support, and things such as max loops before there is actually much of a real world need for it. So chances are the next kernel update or two may well see this limit gone again.
-
I followed the instruction on the SLAX page with TC but no success. mknod succeeded but losetup did not recognize the loop device even if it was below 256 :(
Next I will try it on SLAX itself.
-
That is the same behavior I noticed running out of loops at the standard 80 even when the loop devices are there but max_loop not specified. Supposedly without max_loop being specified the loop mounts are unlimited, at least until an error occurs when that function runs out of it's allocated (128kb?) memory.
The diff file between loop.c in 2.6.26 and 2.6.29.1 is 9kb, so there are some changes that have taken place. And Slax uses 2.6.27 if I recall, which probably shares 2.6.26's behavior.
-
And Slax uses 2.6.27 if I recall, which probably shares 2.6.26's behavior.
As far as I remember instructions on SLAX WEB were there already when it was using 2.6.24 Kernel. But lets try and see what Tomas cooked :)
-
When I initially phrased the question I was actually just theoretically concerned. At the moment I only use a few extensions on my old machine. But I could imagine that a full desktop might run out of this number.
I was just concerned that the great concept of TC might eventually face a serious problem, which would be a pitty.
But then again, one could load system related stuff into RAM (the other distros do that anyway) and selectively mount applications. A way to unmount a tcz (and thus freeing slots) would, however, be a very nice option!
fladd
-
A way to unmount a tcz (and thus freeing slots) would, however, be a very nice option!
fladd
This brings us back full circle to the uninstall applications without reboot discussions.
-
A transient mode?
wrapper mounts application on invocation and umounts on exit?
-
If applications are self contained ala OSX then yes.
Otherwise you can hang your system if you unmount the wrong thing.
-
umount should fail if anything in the extension is still open, for example application is open in two windows.
-
True only for currently not in use, but...
then when it is assumed to be there for use by another program?
There is no indication for that which is a "top level" application versus that which may be required by another. For some it may be obvious for others not so. Heck, the dep files are still not settled. See the latest posts.
But, hey, how hard is a umount. If you like it do it.
-
Actually the application itself could include a wrapper program that gets installed by the startup script.
This wrapper can do the (mount if not present)/(run the real app)/(umount).
No change is needed in the system.
-
Gerald -
There is and were scripted methods of uninstalling tcz's, one was tcz-uninstall which I put a lot of time into and it is one I still use as a personal script. But in time I came around to agreeing with Robert on the potential issues of uninstalling programs on a running TC system. One issue is the "real" files that get copied to the system by the tcz startup script. If removed, you may be removing a file that overwrote a system file and therefore your system is broken. If not removed, you have pieces left of an extension that equate to a half uninstalled app. Take python for example. Uninstalling the symlinks for python leave the python executable in the system without the rest of the extension, leaving you with a broken python. Not to mention the issue of dependencies. I know which apps I can remove safely and what they might break dependency wise, but not every user will. For those reasons mainly, I put tcz-uninstall to pasture.
The correct and safe way to uninstall and upgrade apps is to do it in safe mode, and there is an app in the base for that.
But lets not get in to a debate about uninstalling or upgrading here, there are existing threads that deal with that. This one needs to stay with maximum tcz mounts, which has pretty much reached it's conclusion.
-
I also continue to use tcz-uninstall.....all the time. I'm a little unclear about what you are saying, because it doesn't uninstall dependencies, and I'm not sure why someone would want to use the exec after uninstalling. Perhaps you're right though...assume the worst and everyone who knows better will continue to use it. Yeah, don't use tcz-uninstall. It's not correct .
edit: removing files that have overwritten system files ?? :o
-
Appsaudit is in base and is the official way of dealing with deleting packages.
And for the second time, this is not the thread to discuss uninstalling. Do so in the relevant threads.
-
You are all doing a great job. I like the improvements you are making in Tiny Core. I don't want to add any extra work. However, here is something to think about.
At the present time, there are over 160 dependencies which are only required by one program.
Some of these may be required by future programs.
Some are unique to one program.
In future, these unique extensions could be combined.
For example, iptables and firewall are only used together, and could be combined.
I know there may be a graphical firewall interface in the future.
A bit of trivia. Dependencies required by the most others are:
expat2.tczl
fontconfig.tczl
glib2.tczl
graphics-libs-1.tczl
libxml2.tczl
pixman.tczl
pango.tczl
cairo.tczl
These are all dependencies of over 100 extensions.
Some are duplicate, that is dependencies of dependencies.
-
When two items are practically never used apart from one another, like SDL, tck/tk, ogg-vorbis, and such, there is some leeway in how the extension maker decides to package it. I normally prefer the modular approach, unless an extension is self contained.
As to how this relates to the mounted loop limit that is apparently in place, I see no need for us to alter our course when it comes to modularity. It appears the last commit in loop.c in the kernel was the one that did away with the loop limit:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=history;f=drivers/block/loop.c;hb=73285082745045bcd64333c1fbaa88f8490f2626
Even if the limit was reimposed before 2.6.29, my hunch is that it will be raised or done away with in the near future. It is of interest given our modular system with the option of loop mounting, but having a limit of 256 is not a cause for alarm.
EDIT: FWIW 2.6.31 allows mounting more than 256 loops, tried it on my Lunar box. So the limit has been dealt with on the kernel end and will not be a concern in the long run.