Max tcz mounts

[roberts]

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.
 

[bmarkus]

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.

[Jason W]

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.

[bmarkus]

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.

[Jason W]

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.  

[bmarkus]

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

[fladd]

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

[bigpcman]

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.

[gerald_clark]

A transient mode?
wrapper mounts application on invocation and umounts on exit?

[roberts]

If applications are self contained ala OSX then yes.
Otherwise you can hang your system if you unmount the wrong thing.

[gerald_clark]

umount should fail if anything in the extension is still open, for example application is open in two windows.

[roberts]

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.

[gerald_clark]

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.

[Jason W]

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.

[jpeters]

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 ??