They do persist so e.g. package installs survive reboots, but of course i am limited to ~1 GB
I even tried creating another partition on that drive, mounting it, confirming free space with df is 450GB, and yet still any writes go to cached memory.
I tried with gpt (uefi target) and mbr (normal target)
Is there a way to address this or i have to boot from usb?
if it's "written" to the cache, it's not really written, is it ?
what 1GB ? and what cache ?
you need to provide additional details.
For instance i have started a rsync process for a few seconds, i stopped it of course, normally used memory is 100M with a few MB under cached.
I try running 'sync' and nothing happens.
if i run 'echo 3 > /proc/sys/vm/drop_caches', the files get deleted and the memory is freed, (also gets freed if i delete the files with rm).
But if i reboot, the files persist somewhere (no idea where, /overlay is empty) and the cached/used memory is the same, never to be freed.
the top four are RAM, if you reboot, whatever was in there is gone.
It somehow stays, again i have no idea why, i have never seen this before.
I will end up booting from usb for now.
that's technically impossible
I don't get it, now it's writing to rootfs but the stats are screwed up
Platform is some intel braswell embedded pc.
Impossible to say, since you're not telling us what exactly you're doing.
Running rsync to host a mirror of something.
Still insufficient info.
Under any serious request i will provide more info, i just don't know what to.
Atm it's still going, after it's finished i will report if 'echo 3 > /proc/sys/vm/drop_caches' corrupts the files in any way.
If not that can mean simply that the webui is misreporting caches as used?
I am not sure I understand the issue here...
When you read or write something to disk, a copy of the data is kept in RAM, so it's normal that the size of the cache increases when you perform read/write operations, and there is nothing to be fixed here.
The cache is flushed when the device reboots, because it is stored in RAM, and it does not make sense to persist the cache on a physical device. Perhaps what you see after the reboot is some other data, that also goes to cache, but not the same data as before the reboot.
On the other hand, if you were not looking at that page, would you have noticed any odd behavior?
1 Like
No, there is no other odd behavior, i just let it run and the available memory is OK. I have tested my other theory and the recently written files are still intact after drop_caches.
The conclusion i can draw is that: disk cache is mistakenly treated as buffers, which the webui treats as used.
Sorry for the misleading title in the beginning.
1 Like
Pretty sure you can reproduce this on any Linux dist, if you use the same commands as Openwrt.
2 Likes
I haven't looked at how uci references /proc stuff honestly, but on the previous armv7 device it certainly didn't report like this.
They are, but since it no longer is in RAM if you want one of the files it will have to be read from the flash or disk again, which is slower.
The main point is that when a program demands RAM, the kernel will immediately dump some cache (except of course that of a write not yet committed to disk) automatically to free it up. There is no need to fret over large amounts of RAM "tied up" as cache.
Yes there is endless discussion of how the kernel uses RAM.
1 Like
With all due respect I understand how kernel caching works. It's just that cosmetically it looks weird here.
Again for example the old armv7 device reported caches just under cached, not under used, so that's why i thought that. (too bad i don't have an example of /proc/meminfo from it)
Moreover here even the buffered (e.g. dirty/writeback) does not increase over 1 MB, no matter how i set dirty ratio/centisecs, which initially made me think writes were not commiting, i was wrong of course, that cheap ssd is fast enough to commit 50MB/s of writes immediately.
What i want to find out is someone try to replicate this, out of pure curiosity.
It's not an urgent matter as it works now, i apologize if i expressed this in any other way.