WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Max Boot to RAM Size  (Read 546 times)

Offline limeblack

  • Jr. Member
  • **
  • Posts: 63
Max Boot to RAM Size
« on: February 19, 2017, 02:41:27 PM »
This is a rather funny question but I have created boot cds from tinycorelinux that allow you to boot into RAM and then eject the cd.

What is the maximum size of such file systems?
Is this limited by RAM or the Swap size?  I would assume so.
Would it be increased if I burned the file system to a blueray drive?

Online polikuo

  • Full Member
  • ***
  • Posts: 193
Re: Max Boot to RAM Size
« Reply #1 on: February 19, 2017, 05:52:29 PM »
What is the maximum size of such file systems?
Would it be increased if I burned the file system to a blueray drive?

As far as I know, iso files (ISO 9660) has the upper limit to 32G.
Since the entire repo of 7.x, x64 platform doesn't exceed 8G, that won't be a problem for you.

Is this limited by RAM or the Swap size?  I would assume so.

FYI, my computer:
CPU: i5-4440
RAM: 16G

Running virtualbox with 3 processing units, and 9G of RAM.
No swap partition, boot code without nozswap.
Loading every single extensions takes about 10 minutes.
Checking memory with "cat /proc/meminfo"

Code: [Select]
MemTotal:        9206224 kB
MemFree:          248016 kB
MemAvailable:    1772452 kB
Buffers:            6892 kB
Cached:          8562216 kB
SwapCached:            0 kB
Active:           427472 kB
Inactive:        8215260 kB
Active(anon):     305064 kB
Inactive(anon):  6887920 kB
Active(file):     122408 kB
Inactive(file):  1327340 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       2281788 kB
SwapFree:        2281788 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         73612 kB
Mapped:            46128 kB
Shmem:           7119364 kB
Slab:             283568 kB
SReclaimable:     119664 kB
SUnreclaim:       163904 kB
KernelStack:        2496 kB
PageTables:         2804 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     6884900 kB
Committed_AS:    7423652 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       15888 kB
VmallocChunk:   34359718180 kB
AnonHugePages:     14336 kB
DirectMap4k:      153536 kB
DirectMap2M:     9283584 kB

In short, if you're not limited by the hardware, anything is possible.  ;)

P.S. with copy2fs.flg and copy2fs.lst
« Last Edit: February 19, 2017, 05:56:53 PM by polikuo »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 9524
Re: Max Boot to RAM Size
« Reply #2 on: February 20, 2017, 04:28:03 AM »
RAM + swap + some more thanks to zswap.
The only barriers that can stop you are the ones you create yourself.

Offline Misalf

  • Hero Member
  • *****
  • Posts: 1548
Re: Max Boot to RAM Size
« Reply #3 on: February 20, 2017, 07:12:14 AM »
I was wondering what is a reasonable way to check the current RAM consumption.
Maybe this is interesting for the OP as well so I'm posting here.

I'm subtracting buffers and cache to avoid linux-ate-my-ram confusion and adding shared memory as it contains  tmpfs, which I believe includes zswap?
Using  awk  it looks like this
Code: [Select]
awk '/^MemTotal:/{ram=$2} /^Cached:/{ca=$2} /^Buffers:/{bf=$2} /^MemFree:/{fr=$2} /^Shmem:/{sh=$2} END {used=ram+sh-(fr+ca+bf); perc=(used/ram)*100; if (used>1048000) {used=int(used/1048576); unit="G"} else {used=int(used/1024); unit="M"}; printf "%d%sB %d%%\n", used, unit, perc}' /proc/meminfo
Does it make sense?
Download a copy and keep it handy: Core book ;)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 9524
Re: Max Boot to RAM Size
« Reply #4 on: February 20, 2017, 10:33:56 AM »
Some cache can't be purged (because it's used by the root tmpfs), so if you're ok with purging the cache, "sync; sudo cache-clear; free" will show right numbers.
The only barriers that can stop you are the ones you create yourself.

Offline Misalf

  • Hero Member
  • *****
  • Posts: 1548
Re: Max Boot to RAM Size
« Reply #5 on: February 20, 2017, 11:01:08 AM »
Hmm, I guess it's more complicated than I thought. I was thinking putting cache an buffers out of the equation would make cache-clear unnecessary.
The above awk command reports 96% usage after I filled the /tmp directory. So maybe enough for a frequent check (I'm using it in tint2) but not for reliable results?
Download a copy and keep it handy: Core book ;)