printf in /init, it has missing "f"

[nick65go]

Code: [Select]

tc@box:~$ grep Mem /proc/meminfo
MemTotal:        7078652 kB
MemFree:         5904004 kB
MemAvailable:    6046176 kB
tc@box:~$ grep MemFree /proc/meminfo
MemFree:         5904036 kB
tc@box:~$ grep MemFree /proc/meminfo | awk '{print $2/3}'
1.96799e+06
tc@box:~$ grep MemFree /proc/meminfo | awk '{print $2/3}' | cut -d. -f1
1
tc@box:~$ grep MemTotal /proc/meminfo | awk '{print $2/3}' | cut -d. -f1
2
the result value (1 or 2) is useless for nr_inodes

Code: [Select]

mount / -o remount,size=90%,nr_inodes=$inodes

so is a missing "f", should be printf (not print) in awk '{print $2/3}'

Code: [Select]

tc@box:~$ awk '/MemFree/ {printf "%d",$2/3}' /proc/meminfo
1920377
tc@box:~$ grep MemFree /proc/meminfo | awk '{printf $2/3}' | cut -d. -f1
1920360
EDIT: What is know-how in dividing FreeMem by 3? Why not 4, or 3.14 etc?

[nick65go]

BTW, this mistake started in the past, beginning with TinyCore version 5.4 (kernel 3.8.13) on 32 bits, if somebody has the curiosity to check it.

[Paul_123]

Interesting,

Seems awk is doing that based on how much memory is free.......call it 3 times and get a different result (obviously free memory is changing all the time).  This is on my rpi4 with 8GB of ram.

Code: [Select]

tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{print $2/3}' | cut -d. -f1
2616180
tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{print $2/3}' | cut -d. -f1
2616096
tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{print $2/3}' | cut -d. -f1
2


However, so does printf

Code: [Select]

tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{printf $2/3}' | cut -d. -f1
2616124
tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{printf $2/3}' | cut -d. -f1
2
tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{printf $2/3}' | cut -d. -f1
2

Probably need to format the print output

Code: [Select]

tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{printf "%d" ,$2/3}' | cut -d. -f1
2616321
tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{printf "%d" ,$2/3}' | cut -d. -f1
2616332
tc@piCore64_Devel:/$ grep MemFree /proc/meminfo | awk '{printf "%d" ,$2/3}' | cut -d. -f1
2616321

As for the correct inode ratio, I'm sure there is some logic somewhere.

[nick65go]

I think it is not calling awk for 3 times in a loop, but it is FreeMem divided by 3. AWK has nothing to do with memory, it about mount parameters pre-calculated.So maybe inode number has a size 1/4 of mem-tmp-filesize, so ratio is 1/3 etc. And maybe is specific to temp_filesys only to gain some speed?
I wish to undestand the logic also. Plus before kernel 3.8 it was not necesary for mount in RAM with parameter nr_inode. I tested on TC 11.1 x64 with 8GB RAM. Maybe it is (again) a bug in busybox 1.31.1 syntax. FYI: [bysybox] mount seems to ignore the unsuitable parameters, so no harm; just curios about the logic for current kernel 5.x.

[Greg Erskine]

On my RPi4B - Linux pCPJustBoom 4.19.122-pcpCore_v8 #1 SMP PREEMPT Tue May 26 20:10:39 EDT 2020 aarch64 GNU/Linux

I am getting a proper result 100% of the time. No weird results!

[curaga]

Do you have GNU awk loaded? In my tests busybox awk doesn't do e6 rounding, it requires hundreds of millions before it starts to round.

In any case, that will affect very large memory systems, so pushed a fix.

[nick65go]

no GNU awk explicit loaded by me. Maybe some extensions load it, but very improbable.
anyway, thanks for fix, i saw it at https://github.com/tinycorelinux/Core-scripts/commit/f92dbfe23a97ca757b2fc4987b726528d3b2ac72
may i, how about the logic/know-how for MEM div 3 for inode of tmpfs?

[curaga]

I don't remember, sorry.

[nick65go]

sorry i am not on linux to test it now, but

why

Code: [Select]

inodes=`grep MemFree /proc/meminfo | awk '{printf("%d\n", $2/3)}'`why not just something like :

Code: [Select]

inodes=`grep MemFree /proc/meminfo | printf "%d\n", $2/3anyway  i guess that is just mili-seconds diff in speed.

[nick65go]

Looking over https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt , Updated: KOSAKI Motohiro, 16 Mar 2010 (so old!)
the string "nr_inodes" shows only 3 times.

1. "So 'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs' will give you tmpfs instance on /mytmpfs which can allocate 10GB RAM/SWAP in 10240 inodes and it is only accessible by root" <--is Not very useful.

2. "nr_inodes: The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower." <--so we need to specify something about inode (but not necesary 1/3 of RAM)

3. "if nr_inodes=0, inodes will not be limited.  It is generally unwise to mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many cpus making intensive use of it." <-- like most modern forced UEFI_64 with shame-less multicore CPU (> 4+ cores).

But here is the thing, we use 90% of RAM, and we use zram for compressed_swap in memory. So no danger to exhaust all RAM inodes, I think.
So, if I am not wrong, nr_inode parameter for mount can be zero (aka missing)?

[nick65go]

here is what i understand from kernel docs.
https://www.kernel.org/doc/html/latest/filesystems/vfs.html?highlight=inode

"Inodes are filesystem objects such as regular files, directories, FIFOs and other beasts. They live ...in the memory (for pseudo filesystems).
A single inode can be pointed to by multiple dentries (hard links, for example, do this)".

case1: [very few inodes in RAM]: we hit ourself in testicles, because we can not have many files in system ("/" from core.gz loaded into RAM). So more free RAM for the few little programs (files) that demand big memory when they run; like virtual machines, video editors.

case2: [very many inodes in RAM]: we can keep huge number of files/appls in the system, but the memory for them to run is limited (TotMem less prog-size); like a lot of normal programs (vlc, libreoffice, firefox). come on, how many appls do you run simultaneously? because you compile the kernel in background, during listening to music, and see a movie, and... blah..

Anyway linux will swap pages from memory to swap file (in RAM, or on disk) if user used "ALL phisical RAM" [=full 90% TotMem]. If this happens, linux will run slower, and then user can take actions, like manualy delete /home/*caches. /tmp etc. I would prefer case2, because (in emergency) I can delete files from system (/usr/local.. whatever) to free RAM memory for other programs to run.

[nick65go]

I think I get it: it is not an easy/general answer. It depends on the AVERAGE size of files on system. A simple (in layman terms) clarification I found at:
https://www.howtogeek.com/465350/everything-you-ever-wanted-to-know-about-inodes-on-linux/

There I saw an example of a ext4 system, with block size=4096 bytes (=4k) and ratio of one inode per 16 KB of file system capacity. so a ratio of inode/TotalCapacity = 4k/16k =1/4. But, in that example, file storage (storage of the inodes and directory structures) has used 28% of the space on that file system, at the cost of 10% of the inodes! So the capacity of files_system has depleted quicker than consuming the inode numbers. Wow, basicaly 28% /10% =2.8 , near 3 times faster consumed block than inodes (in that example).

for core.gz loaded in tmpfs RAM, the block size=4k (kernel page size), so for a ratio inode/capacity =1/3, it results aprox. 4/(1/3)=12 KB average file size asumption. If the files (on average) are bigger than 12KB (each), the space ocupied by them (in ram PAGES or 4k each) will rise to max capacity [90% MaxMem] faster than inode depletes.

[Rich]

Hi nick65go

... for core.gz loaded in tmpfs RAM, the block size=4k (kernel page size), so for a ratio inode/capacity =1/3, it results aprox. 4/(1/3)=12 KB average file size asumption. ...

Not quite. The command:

Code: [Select]

grep MemFree /proc/meminfo | awk '{print $2/3}' | cut -d. -f1is dividing the number of  1K Bytes  by 3, not the number of  4K Bytes.  So for every  3K Bytes  of MemFree you get 1 inode.

Why divide by 3 ?
It comes down to achieving a balance:
If you run out of RAM, the file system is full.
If you run out of inodes, the file system is full.
If you have a lot of tiny files, you need more inodes.
If you have a lot of large files, you need fewer inodes.

[nick65go]

thanks Rich for the correction, of average file size = 3 KB assumption.
how about my post #9 :"if nr_inodes=0, inodes will not be limited" ? any danger/advantage?

[Rich]

Hi nick65go
Aside from item #3 in post #9, I can offer 2 comments:
1. The number chosen (for Tinycore releases) should be based on suitability for the majority of people, not specialized hardware setups.
2. You would never sign a blank check and give it to a stranger to fill in the details. The same holds true for  nr_inodes=0.  No surprises.