Frugal Install + extensions = too much ram used


Forum: HD Install
Topic: Frugal Install + extensions = too much ram used
started by: xmrkite

Posted by xmrkite on Jan. 26 2008,05:56
Hello. When i do a traditional hard drive install and load mydsl extensions, they take up disk space. When i do a frugal install and load up mydsl extensions, they take up ram. I need to have them take up hard drive space and not ram.

I'm storing the mydsl extensions on a hda2, while the frugal partition is hda1. So since the extensions are "local" in one sense, why do they have to "load" into ram.

Any ideas or options?
-Thanks

Posted by lucky13 on Jan. 26 2008,06:03
Yes, it helps to read the documentation. Start with booting with the cheatcode "base," which loads only DSL and not the extensions you have. See also:
< http://www.damnsmalllinux.org/wiki/index.php/Bootlocal.sh >
< http://www.damnsmalllinux.org/wiki/index.php/Cheat_Codes >
(edit: changed link and added cheat code link)

Posted by roberts on Jan. 26 2008,15:00
Use uci type extensions.
Posted by xmrkite on Jan. 26 2008,17:10
Thanks for the tips, but here's what i need to install:

cron30.dsl - small dsl
feh.dsl - small dsl
gnu-utils.dsl - big dsl, this one is killing my ram
imagemagick - i'll use the uci for it
rsync.dsl - small dsl
samba.dsl - kinda big dsl too
unclutter.dsl - small dsl
xbindkeys - small too

so the main two that are killing my ram are gnu-utils and samba. Any ideas on how to load these in a frugal install without using a lot of ram? The only reason i need gnu-utils is so i can get the full version of wget. I'm all ears to a better way to get the full wget. Also, would a remastering fix the high ram usage by somehow integrating those extensions into the iso file and not having to load up all the dsl extensions into ram?
-Thanks

Posted by curaga on Jan. 26 2008,17:17
Yes, remastering would remove all extra ram usage.

Other ways are turning those .dsl's to .unc's, which use less ram than .dsl's. There are some unc's for those already, gnu-utils.unc comes to mind.

Posted by xmrkite on Jan. 26 2008,17:35
Can the unc extensions be used in a frugal hard drive install?

I like the idea of using the extensions over remastering so that i can easily get the latest versions of dsl linux.
-Thanks

Posted by roberts on Jan. 26 2008,17:42
Easy to extract wget from gnu-utils and even save it as a .dsl

$ mydsl-wget gnu-utils.dsl system
$ sudo su
# tar -C / -zxvf gnu-utils.dsl usr/bin/wget

Now to turn around as save it as a .dsl simply

# tar -C / -czvf wget.dsl usr/bin/wget

----

rsync is alread in DSL, no need to use rsync.dsl

MyCron is a simple but useable cron already in DSL

There is a new samba uci version in testing.

Posted by xmrkite on Jan. 26 2008,17:45
Roberts, thanks for the tips, i'll try those out later today. With all these extension types: dsl, uci, unc....what are the advantages of each type? Can each be used in any type of install? Why use a dsl when there is a unc or uci of the same extension, and vice versa?
-Thanks

Posted by lucky13 on Jan. 26 2008,18:49
Quote
what are the advantages of each type?

DSL and UNC load to traditional file paths, e.g., /usr/bin for binaries and /usr/lib for libraries. The difference is UNC does it via unionfs overlay. This means UNC doesn't load into RAM like DSL extensions do. This leaves you with more RAM for more things. If you're in a limited RAM environment, the UNC extensions may be more useful. You wouldn't notice any other difference because they load to the same paths.

UCI and tar.gz are self-contained. The difference is UCI extensions use compressed loops allowing them to be mounted/unmounted at will (via same mydsl-load command).

More on the wiki:
< http://www.damnsmalllinux.org/wiki/index.php/Category:MyDSL >
(edited grammar)

Posted by xmrkite on Jan. 26 2008,21:26
So for a frugal install...

-Hold of on dsl extensions where possible since they load in ram (ramdisk)....check
-UCI/tar.gz and UNC, i see the difference, but I don't see which would be better to use if a program is available in both extension types.

Plz help clarify this one.
-Thanks

Posted by Juanito on Jan. 27 2008,04:05
The uci type extension is probably best - it installs to /opt so it does not disturb the base dsl system, it hardly uses any ram and it can be unloaded cleanly from the system once you have finished with it.
Posted by curaga on Jan. 27 2008,05:58
The key difference between uci and tar.gz is, that if you have a persistent opt set up, you can install tar.gz extensions permanently and not have them load up every boot, like ucis. This has a minor speedup, bigger on older computers.

The only part where having an unc over uci/tar.gz is a compiling extension, because then you don't have to enter some variables, or gnu-utils, because some programs hardcode for example less to /bin/less and expect it to be there.

Posted by andrewb on Feb. 04 2008,22:52
For low RAM systems (I run with 64MB - maximium possible!) stick to UCI extensions where possible as explained by juanito, but the UNC extension is the only way to go for extensions that require write access to files contained in the extension or need to place files in the read-only areas of the filesystem (i.e. anything that would otherwise be a .dsl extension). I use samba, gtk2, gnumeric, gnu-utils as the UNC versions & still some RAM left  & a usable system. If the extension you want isn't available as a UNC there is a DSL2UNC script around on the forums that will do the conversion for you. If you use this script also use the declobber script at the same time, just in case there are any unwanted empty directories still lurking in the original .dsl extension.

Roberts has hinted at removing unionfs due to problems with stability. I would hate to see this as it is only since unionfs was included that I have been able to rely on DSL on this low RAM system. Since unionfs was added I have rarely had to resort to the WIN98 installation still remaining on the machine (one of the big problems was Excel files - I needed Gnumeric for that). .dsl extensions are a no-no for low-RAM systems as they have to copy large chunks of the filesystem to RAM in order for them to be writable (the dreaded mkwritable script - run it & see how much RAM you have left then after using a few extensions!). To maintain the goal of supporting older hardware the use of some form of overlay filesystem looks like a pre-requisite for DSL.

Posted by lucky13 on Feb. 04 2008,23:52
Quote
Roberts has hinted at removing unionfs due to problems with stability. I would hate to see this as it is only since unionfs was included that I have been able to rely on DSL on this low RAM system.

Even if it's not included in the next base, it will likely be available as an extension for those who either need or choose to use it.

Posted by andrewb on Feb. 05 2008,00:41
Quote (lucky13 @ Feb. 04 2008,08:52)
Even if it's not included in the next base, it will likely be available as an extension for those who either need or choose to use it.

I don't understand the inner workings of the overlay filesystems, but would such an extension not require write access to some of the core areas? This would negate the usefulness of such an extension on low-RAM systems - the very are a where it is most useful.
Posted by ^thehatsrule^ on Feb. 05 2008,00:50
Quote (andrewb @ Feb. 04 2008,19:41)
Quote (lucky13 @ Feb. 04 2008,08:52)
Even if it's not included in the next base, it will likely be available as an extension for those who either need or choose to use it.

I don't understand the inner workings of the overlay filesystems, but would such an extension not require write access to some of the core areas? This would negate the usefulness of such an extension on low-RAM systems - the very are a where it is most useful.

That's true.. one would need a unionfs.uci (which looks possible...)
Posted by lucky13 on Feb. 05 2008,01:52
Quote
I don't understand the inner workings of the overlay filesystems, but would such an extension not require write access to some of the core areas? This would negate the usefulness of such an extension on low-RAM systems - the very are a where it is most useful.

I don't know why it would work any differently as an extension than it does now. Or did before it was included in the base. The difference is you should be able to benefit from 2.6-only improvements (iirc, 2.4 development has ceased).
< http://distro.ibiblio.org/pub....sl.info >

Posted by andrewb on Feb. 05 2008,03:01
Now we have a catch 22! Unless unionfs can be created as a UCI loading it will either require the mkwriteable script to be run, or it needs to be a UNC. A UNC of course requires unionfs,......
Posted by curaga on Feb. 05 2008,07:03
Unless a readymade symlink for the module is done in /lib/modules to /opt/unionwhatever.
Posted by ^thehatsrule^ on Feb. 05 2008,07:38
You can just insmod it... unless for some odd reason the module will be needed even after it has been loaded into memory?

EDIT: looks like it works (from quick memory)
- tested with 3.4.x
- boot with legacy
- remove unionctl and module
- run depmod and/or change modules.dep
- copy unionctl and module to a some dir*
- insmod and run mkunion
- mydsl-load something.unc and test it

*: for some reason, unionctl was not found even after symlinking from /opt/bin, so I just restored the original location

note: running mount shows unionfs on /ramdisk/foo instead of /KNOPPIX/foo

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.