Project

General

Profile

Actions
Copy link

Bug #10420

closed

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

Added by Adrian Zaugg over 4 years ago. Updated over 4 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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.

Actions
Copy link
 #1

Updated by Jim Pingle over 4 years 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.

Actions
Copy link
 #2

Updated by Adrian Zaugg over 4 years ago

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

Actions
Copy link
 #3

Updated by Jim Pingle over 4 years 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.

Actions
Copy link
 #4

Updated by Jim Pingle over 4 years 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
Actions
Copy link
 #5

Updated by Jim Pingle over 4 years 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.

Actions
Copy link
 #6

Updated by Jim Pingle over 4 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #7

Updated by Jim Pingle over 4 years 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.

Actions
Copy link

Also available in: Atom PDF