Project

General

Profile

Bug #10420

Miscellaneous page with pre-existing RAM disks config can't be saved

Added by Adrian Zaugg 2 months ago. Updated 12 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Operating System
Target version:
Start date:
04/03/2020
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.5
Affected Architecture:
amd64

Description

Having an installation of pfSense using RAM disks one can't save any other changes made on the System->Advanced->Miscellaneous page after Upgrading to 2.4.5. The page presents the error: "Combined size of /tmp and /var RAM disks would exceed free kernel memory." The statement of the error message would be right, if there should be added another RAM disk with the given size to the system in addition to the active one. I guess this check for free RAM doesn't take into account, that there is already a RAM disk existing, using RAM. The check should subtract an existing RAM disk size from the used memory to determine the free space required.

I would expect not changing anything to an existing RAM disks does not show the error.

affected version: pfSense 2.4.5, previous versions were fine.

Associated revisions

Revision 355aa65e (diff)
Added by Jim Pingle about 1 month ago

Factor existing RAM disk usage into kmem calculation. Fixes #10420

Revision 32cd2d98 (diff)
Added by Jim Pingle about 1 month ago

Factor existing RAM disk usage into kmem calculation. Fixes #10420

(cherry picked from commit 355aa65e684431fe435dcf51c92f17659b5b000d)

History

#1 Updated by Jim Pingle 2 months ago

  • Category set to Operating System

I have not seen that happen here when I was testing this initially, but I don't currently have any systems with RAM disks active to confirm right this moment.

#2 Updated by Adrian Zaugg about 2 months ago

I did not see the behavior on another installation I upgraded today neither.

#3 Updated by Jim Pingle about 2 months ago

  • Status changed from New to Confirmed
  • Target version set to 2.5.0

I was able to replicate this on an ARM system (SG-3100).

Kernel Memory before activating RAM disks:

vm.kmem_map_free: 131039232
vm.kmem_map_size: 197795840
vm.kmem_size_scale: 3
vm.kmem_size_max: 328833434
vm.kmem_size_min: 12582912
vm.kmem_zmax: 65536
vm.kmem_size: 328835072

Kernel Memory after activating RAM disks (40M /tmp, 60M /var):

vm.kmem_map_free: 41320448
vm.kmem_map_size: 287514624
vm.kmem_size_scale: 3
vm.kmem_size_max: 328833434
vm.kmem_size_min: 12582912
vm.kmem_zmax: 65536
vm.kmem_size: 328835072

Disk sizes/usage:

: df -h /tmp /var
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       38M    336K     35M     1%    /tmp
/dev/md1       58M     19M     34M    36%    /var

Free Before - Free After = 89718784

So the free amount went down by about 90M but the RAM disks total 100M. I'm not exactly sure why there is a discrepancy in the numbers. It's close but not quite the same.

If we add the configured RAM disk size to the vm.kmem_map_free value before calculating if things fit it should help, but there is still some danger of the calculation being incorrect.

#4 Updated by Jim Pingle about 1 month ago

  • Subject changed from Miscellaneous page with pre-existing RAM disks config can^t be saved to Miscellaneous page with pre-existing RAM disks config can't be saved
  • Assignee set to Jim Pingle
  • Target version changed from 2.5.0 to 2.4.5-p1

#5 Updated by Jim Pingle about 1 month ago

When I got the actual byte counts and calculated better, the numbers came out much closer, only within a couple MB, so that should be safe. Commit coming momentarily.

#6 Updated by Jim Pingle about 1 month ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#7 Updated by Jim Pingle 12 days ago

  • Status changed from Feedback to Resolved

Calculation is correct on 2.4.5-p1 internal testing snapshot. RAM disk space is accounted for properly and used space is not counted against total when saving as it was before.

Also available in: Atom PDF