[BUG?] Ram disk breaks ntopng
Summary Enabling RAM disk break ntopng and add about 2 minutes to boot time. You can reach the ntopng login page, but clicking "login" doesn't do anything. My /tmp was about 1M and /var 122 MB. I would say it was not a size issue, even with 600MB assigned to each, the problem persisted.
I was able to consistently reproduce the issue.
System Intel J3160, 8 GB RAM, SSD 250GB.
How to reproduce: Default installation of pfsense 2.4.4-RELEASE-p2 (amd64) with 1 WAN and 1 LAN.
- Install ntopng from the package manager
- Enable RAM Disk: System / Advanced / Miscellaneous => "Use RAM Disks"
- ntopng is broken
Unchecking "Use RAM Disks" fixes the boot time and ntopng works once again.
I was able to replicate it on a test environment using a default installation on VMware.
I wonder how many people have this issue.
bmeeks last edited by
I don't know anything specifically about the ntopng package's use of disk space, but some other packages (namely the Snort and Suricata ones I maintain) store files in /var/db and directories underneath there. When using a RAM disk for /var, then those directories are erased with each reboot. Perhaps the package is trying to rebuild some database or some other file that it expects to persist in that directory path ???.
In my view, with today's SSD technology (and you are showing a 250 GB SSD in your setup), there is no real benefit to using a RAM disk. In fact, in many cases it will just cause problems. I have had a pretty big list of Snort/Suricata users posting about issues with rules updates, but it turned out in almost every case it was simply their use of a RAM disk that was not large enough (it ran out of free space). The reason for the RAM disk feature in pfSense traces back to the days of NanoBSD and old-style flash memory that had very limited read/write cycles. Those limitations are not nearly so restrictive for modern SSDs. So why not just abandon the RAM disk approach?
I see your point @bmeeks. Just wondering if there is a place where I can find the typical write throughput for a vanilla pfSense installation. Googling around, I found people having multiple SSD failure.
Grimson last edited by
Googling around, I found people having multiple SSD failure.
That's because ppl are trying to buy as cheap as possible and getting trash SSDs, or old ones from the first few SSD generations and those were prone to die fast. My current pfSense installation runs on a 64GB Kingston SSD for about 2 years, according to S.M.A.R.T. data lifetime writes are a bit over 6 Terabyte and the remaining lifetime is at 97%. That's with pfSense running continuously and pfBlockerNG with daily updates.
bmeeks last edited by
I agree wholeheartedly with @Grimson here. Modern SSDs are more than reliable enough. The main "C: drive" in my Windows 10 machine is a 500 GB SSD. The PC is on a UPS and never turned off. It has been running at least 2 years straight, 24x7, save for reboots to apply updates and two power outages that outlasted my UPS battery. I've had zero issues with the SSD.
I also agree here. I'm not aware of any particular issue with ntop-ng but it would need to allow for ram disks and may not be currently. However you should be able to use an SSD without worrying about disk writes if it's even vaguely current and decent quality.
Thanks for the feedback, I try without RAM disk.