Project

General

Profile

Actions

Todo #13508

open

Uncouple RAM Disk size from available kernel memory

Added by Steve Wheeler over 1 year ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Web Interface
Target version:
Start date:
Due date:
% Done:

60%

Estimated time:
Plus Target Version:
24.07
Release Notes:
Default

Description

Now that we are building RAM disks with tmpfs the size is no longer restricted by the available kernel memory but we are till checking for that and limiting the size.

This is only significant in armv7 and really only the 3100 where kernel memory is limited but does apply to all architectures.


Related issues

Related to Regression #14351: Ram Disks are not created at boot.ResolvedJim Pingle

Actions
Actions #1

Updated by Flole Systems over 1 year ago

Kinda the same as #13479, or at least both would be solved if the check is removed completely.

Actions #2

Updated by Jim Pingle over 1 year ago

  • Assignee set to Jim Pingle
  • Target version changed from CE-Next to 2.7.0
  • Plus Target Version changed from Plus-Next to 23.05

We can't remove the check entirely but it would need to be adjusted for whatever limits tmpfs may have. For example, total non-kernel memory size, with some allowances for system processes and so on.

But that's not something we'll be doing for the next Plus release yet, better safe than sorry here for the time being.

Actions #3

Updated by Jim Pingle about 1 year ago

  • Status changed from New to In Progress

Note to self: tmpfs data can get moved to swap under memory pressure, which further extends its potential capacity, so we may also want to factor in available swap size into any limitations here.

https://man.freebsd.org/cgi/man.cgi?query=tmpfs&apropos=0&sektion=0&manpath=FreeBSD+14.0-CURRENT&arch=default&format=html

Actions #4

Updated by Jim Pingle about 1 year ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #5

Updated by Chris Linstruth 12 months ago

I set /tmp to 200000 on a small VM. It was accepted and rebooted. On boot I got this:

RAM disk creation failed. Reverted to traditional storage. Check RAM disk sizes. 2023-04-30 19:17:55@

If that's the way it's supposed to work, it works fine.

Actions #6

Updated by Jim Pingle 12 months ago

It should have rejected the change if there was not enough free memory. Unfortunately since the amount of memory in use at any given time is dynamic, it can't always be accurate.

How small is "small"? It should have reported the amount of space in use and free memory under the fields when you set it up, what did it show there?

Actions #7

Updated by Jim Pingle 12 months ago

  • Status changed from Feedback to In Progress
  • % Done changed from 100 to 90

Looks like there is still a problem here. The memory calculation in source:src/etc/rc.ramdisk_functions.sh is still using kernel memory only to compare, it needs updated the same way that the GUI code was updated.

Actions #8

Updated by Jim Pingle 12 months ago

  • Plus Target Version changed from 23.05 to 23.09

There is a chicken/egg problem here that will need more time to solve properly to allow creating RAM disks at boot that utilize swap space due to their size.

I can update the calculation so it accounts for swap but at the time RAM disks are mounted during boot, swap is not yet configured. But we can't configure swap before mounting the drives because when configuring swap, before using it, it needs to be able to run savecore to store crash dumps in /var/crash, but var may not be available because it should be a RAM disk. So either the calculation in the shell script will need to be more creative (checking partition sizes, not active swap sizes) or we'll need to figure out a way to reorder the boot process. If we change the calculation, existing RAM disk contents may not fit because swap isn't available yet.

Moving swap initialization up higher seems better, but that would mean changing where savecore puts the crash dumps.

Actions #9

Updated by Jim Pingle 12 months ago

Actions #10

Updated by Jim Pingle 12 months ago

  • % Done changed from 90 to 60

The last commit, b10998b1951b3e0d1cb74449a6b6dd333b9d292a, did not work on some systems and triggered a boot time failure of RAM disk initialization, so that commit has been reverted for the time being.

This appears to be due to swap not being configured yet, the variable is ending up empty and the calculation is failing:

# echo $MEM_FREE
805548032
# echo $SWAP_FREE

# MEM_FREE=$( /bin/expr \( ${MEM_FREE} + ${SWAP_FREE} \) / 1024 / 1024 )
expr: syntax error

Probably needs a test above there to only add those together if swap is non-empty.

Actions #11

Updated by Jim Pingle 10 months ago

  • Target version changed from 2.7.0 to CE-Next
Actions #12

Updated by Jim Pingle 8 months ago

  • Plus Target Version changed from 23.09 to 24.01

Needs more time to come up with a proper solution.

Actions #13

Updated by Jim Pingle 7 months ago

  • Plus Target Version changed from 24.01 to 24.03
Actions #14

Updated by Jim Pingle about 1 month ago

  • Plus Target Version changed from 24.03 to 24.07
Actions

Also available in: Atom PDF