Webgui slow to make changes after 2.2.3
-
What "fixes" the issue? from disk to disk, regardless of type (flash / spinny) and write rate, isn't necessarily the disk controller, but how much cache the disk controller has to work with.
If it has enough cache to absorb all the random writes and spit them out to the physical layer on its own time, it tells the kernel it has all that data, and you don't see hanging issues.
If it doesn't have enough cache to absorb all the random writes, you wait until it has actually written most of it to the physical layer, then it tells the kernel it has all the data, and this is the hang you experience.
So, it's not a disk speed issue at all, it's that faster / larger / newer disks tend to have better controllers with more cache than slower / smaller / older disks.
It doesn't help that NanoBSD images are not 4k aligned, so writes take even longer than they should on flash & 4k drives. Hopefully this gets fixed for the 2.3 branch, or we get a NanoBSD installer so we can fix it manually.
Want to test? Run a pfSense NanoBSD VM on a system with a RAID controller that has a descent size cache in write-back mode. Now try it with the controller cache disabled. Now try it with the controller cache disabled and running on a true 4k sector drive. Spoiler: good, bad, worse.
-
so, what you are saying is that a kingston CF 266x ultimate card is not 'fast' enough, but the cf card you posted (pictured) is slower and is 'fast' enough?
sorry…but that does not fly in my book. nor make any sense.
i know for a FACT that it is NOT any of the EIGHT different cards that i have tried (with the slowest being the kingston CF 266x ultimate) ..... across multiple hardware specs .... that is causing the slowness.
the ONLY way to actually have the webgui to be productive is to change the nanobsd to r/w .. which for is bad.
downgrading to 2.2.2 on the SAME cards and the SAME hardware...everything runs perfect. in fact i actually am able to achieve slightly better throughput up & down.
so, the bug that was 'fixed' in 2.2.3 for nanobsd introduced this slowness (to virtually unusable) state....
-
As already noted above and even on 2.2.4 release notes: The only thing that helps is switching to permanent RW in Diagnostics - NanoBSD. Stop wasting your time.
…and for a firewall/router .. that is bad & unacceptable for a production environment.
-
All of those points have already been addressed in previous replies. Please read it again and pay attention as I will not repeat myself.
