WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: what are the differences between install the extensions to RAM or mount them?  (Read 8748 times)

Offline mcewanw

  • Full Member
  • ***
  • Posts: 102
Using tinycore 2.5 on old Dell CPx laptop (Pentium III 500 MHz CPU with 256 MB RAM)

In an attempt to find an answer to the question in above post I tried the following:

1. Booted Tinycore 2.5 without any mounted tcz extensions and ran busybox free

It reported 32048 MB RAM used according to busybox free.

Following a tip I read somewhere from user Curaga, I then ran the command:

Code: [Select]
sync && echo 3 > /proc/sys/vm/drop_caches
a number of times in order to clear any caches being used by the virtual memory system.

That resulted in 30832 MB RAM now used.

2. I now rebooted but included (loop mounted) the bash.tcz extension.

Busybox free reported 33080 RAM used
and after clearing the caches (as above): 31504 MB RAM used.

I temporarily concluded that loop mounting a single tcz uses around 700 kB of RAM [31504 - 30832 (from step 1)].

3. As a check, I rebooted but now included: tcz extensions for bash, file, pppd and pppsetup (i.e. loop mounted four tcz extensions).

Running busybox free said: 35816 MB RAM used
After clearing the caches: 33640 MB RAM used

Hence difference between no loop mounted tcz extensions and using four loop mounted tcz extensions approximately = 33640 - 30832 (from test 1 above)
= 2808 MB (for these four loop mounts)

= roughly 700 kB per loop mount.

If the above is correct, it seems to me, that on low RAM machines (such as mine) it would be very beneficial to combine tcz extensions into one big extension in order to limit the number of loop mounts used. For example using fifty loop mounts would use up approx 35 MB of RAM (i.e. 50 x 700 kB), whereas if you combine all these into one big tcz before loop mounting you would just use up 700 kB of RAM to loop mount that single combined tcz extension.

It would be good, I feel therefore, if someone, who understands tcz squashed file systems, could write and provide a simple tool for combining them into one big tcz extension, which would allow the RAM savings indicated above on usage.
« Last Edit: November 08, 2009, 06:28:01 PM by mcewanw »

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Loop mounted extensions have symlinks in /usr/local.  These symlinks still consume memory in the RAM based filesystem.

Offline Guy

  • Hero Member
  • *****
  • Posts: 1089
Quote
It would be good, I feel therefore, if someone, who understands tcz squashed file systems, could write and provide a simple tool for combining them into one big tcz extension

I started a new subject for this.

http://forum.tinycorelinux.net/index.php?topic=3757.0
Many people see what is. Some people see what can be, and make a difference.

Offline mcewanw

  • Full Member
  • ***
  • Posts: 102
Loop mounted extensions have symlinks in /usr/local.  These symlinks still consume memory in the RAM based filesystem.

As far as I know, symlinks only occupy about 55 bytes each. A quick look at my /usr/local suggests to me that even the relatively large number of symlinks appearing there don't add up to anything like the RAM used by loop mounting a tcz. For example, I counted around 35 symlinks in my seamonkey browser directory, which would only account for around two kbytes of RAM use in total, unless I am missing something or other in all this.

Offline roberts

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
I would not be concerned as Phillip Lougher. the author, maintainer, copywrite holder, of squashfs has stated that squashfs uses its own cache and will release it when needed by low memory systems.

Additionally, Tiny Core provides other means to support very low memory systems, from PPI to traditional (scatter mode) installations.
10+ Years Contributing to Linux Open Source Projects.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Bytes used to store a symlink depend on the length of the path/filename stored.
This can be stored in the directory, inode, or file. if the name is too long to fit in the directory or inode, it must be stored in the first data block.

Offline ^thehatsrule^

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 1726
To be pedantic, more bytes are reserved due to block sizes afaik