OPNsense Forum
Archive => 17.7 Legacy Series => Topic started by: dcol on November 15, 2017, 05:11:58 pm
-
I notice that OPNsense, when doing a new install, only assigns a portion of the hard disk, or in my case SSD, to the UFS. I used guided installation. Manual Installation locks up in UEFI mode
When I installed on a 64GB SSD it only allocated 28GB to UFS
When I installed on a 128GB SSD it only allocated 76GB to UFS
Why is that and is there a way to expand it to use the full capacity?
[UPDATE] I guess this extra space is used for the swap slice. Not sure what the swap space is used for or if we need it.
-
This was just recently brought up: https://github.com/opnsense/bsdinstaller/pull/8
Long story short: large servers with plenty of RAM and minimal SSDs seem to be hip nowadays. The algorithm for swap space was only ever bound on i386, where the maximum RAM was 4 GB.
Swap will be capped to 8GB in 18.1.
Cheers,
Franco
-
Ok, thanks. I thought that was strange to use so much space for swap when many user now use large RAM and SSD's. Can there be an option to use no swap at all?
Also, I assume to reduce the swap space you will need to do a fresh install of 18.1 to repartitions the disk, then restore from backup. Is the full beta image of 18.1 available for testing this new partition scheme?
-
It is not merged yet. Installer changes are tricky as they require new images, but once that is tested we can build one from 17.7.8. or 17.7.9 for you no problem.
We still want swap partitions by default, it is the only way to do kernel dumps on crashes, but we can probably kill them with a script post install by removing the partition, fstab entry and running growfs to reclaim the free space. Will be back next week with the commands if you ping me or create a GitHub ticket.
There is also an option to use a 2GB swap file instead, but it was tailored for low RAM systems so in high RAM servers we don’t need swap except for those kernel crash records. I think on media smaller than 30 GB we skip swap assuming it’s a CF or SD card. SSD with 32 to 128 hit this unfortunate sweet spot, but capping swap to 8 GB should be ok, except maybe for 64 GB where the ratio is still high.
What do you think? I wouldn’t want to complicate the installer by asking for swap yes/no, but if enough people agree we could evaluate that option. At least in that dialog we could also make clear how big the swap would be, creating transparency and noting that they are useful for crash reports.
Cheers,
Franco
-
I think the best approach is to keep swap at a minimal size as needed by the crash dumps unless the dumps can be sent to the primary slice, or a USB flash stick. A 16-32GB USB stick is less expensive than using a bigger SSD drive just because of the crash dumps.
-
Here comes the ironic part: the full crash dump can include the whole RAM dump, which is why having a bigger swap was handy in the first place. I neither know if we can easily restrict swap space beyond its traditional constraints without interfering with crash dump behaviour nor do I know what a practical minimum value would be if we ignore the memory dump part which we obviously won’t send through the crash reporter.
Cheers,
Franco
-
My $00.02 would be is to look at the standard windows logic for SWAP space that during install it checks the memory and allocates twice that much for the SWAP rather than capping. So it will still have space for 2 dumps?
Thanks
-
That’s why this whole thing started. 32 GB RAM + 128 GB SSD = 64 GB swap partition. We are discussing options to get away from this as the calculation is clearly not meant for modern amd64 server hardware.
-
I know that when setting up the ZFS partitions for a pf box, it had the option of no swap slice when setting it up and that has run fine. That box has 8GB RAM and two mirrored 60GB SSD's. (Soon to be converted to an OPNsense box).
When I tried to use a 60GB SSD on an OPNsense box with 16GB RAM, it took 30GB for swap only leaving me 28GB for the system. Had to bump the SSD to a 128GB. This is why we need a fix for this.
-
I've added a ticket here: https://github.com/opnsense/bsdinstaller/issues/10
We'll have this in time for 18.1-RC. Thanks for the discussion and ideas. :)
Cheers,
Franco