Updated today to latest snap - very slow
-
Okay,
I've been facing this problem since the very first update to 2.1 snapshot. I've tried out a lot and nothing helped, but today I had to restore a backup because of missconfiguration. What can I say: The applying/saving changes on the pfsense are much faster now! Now it takes like 5 seconds to save a change, where I had to wait up to 40 seconds. Please try following thing:
1. Create a full backup
2. Make some minor, not important change
3. Login to the pfsense console and choose to restore a backup
4. Restore the latest backup and restart
5. Check if you see any changesHope this can help someone out.
Cheers,
Szop -
Hmm, interesting.
So the original backup your restored from had been created under 2.1? From what date/snapshot?Steve
-
i think this would be temporary and with more and more changes u do it keeps getting slower coz i had setup a new alix board recently and for a few days it was fast then later it became slow
-
I guess, I wasn't clear enought. The version I'm running on is the latest snapshot: 2.1-BETA0 (i386) built on Sat Nov 10 18:43:12 EST 2012. Today, 11.11.12, I made some changes which doesn't worked out and I had to restore to the last change via console and restart once (I guess it's point 15 in the console, sorry but I'm not in front of the pfsense). Anyway, I'm still on the latest snapshot but the sluggish behaviour is gone. I've also made more than enough changes and it's still fast (created over 15 different VLAN's and also set them up to static IP's). I'll keep you up to date, would be nice to see if someone can reproduce/try this out.
Cheers,
Szop -
@xbipin: Unfortunately you've been right :'(. My pfSense is becomming sluggish again. I'll keep you up to date aboute the situation and I'll try to speed my pfSense up again with this restore function. Thanks for listening ;)
Cheers,
Szop -
better solution for now would be to avoid the rw and then ro calls, simply provide an option in the GUI to permanently set it to rw for now coz being on nanobsd its probably not going to write much to the CF card or whatever storage u use until u make some config change as most will be in the ramdisk so if devs r listening, just avoid the rw and then back to ro call, set it explicitly to rw mode, atleast things will get faster for now, once there is a solution u can switch back to the general behavior
-
I've had a "permanent rw" feature on my to-do list for a while now but haven't had a chance to do it.
It's not really a solution, it just masks the problem.
-
yes indeed its not a solution but for time being u can simply change the rw and ro not do anything but exit silently and on boot simply set the system to rw
-
Sometime during the beta testing of 2.0, Beta 5 I think it was, the scripts for remounting the file system became broken for some reason. Generally speaking it didn't cause any problems, the only way you could tell they were broken was that the file system in Nano remained RW after boot. That was all fine until some people started using a package (not a proper package!) that didn't follow the rules and instead of calling /etc/rc.conf_mount_ro it issued the mount command directly. This still worked and mounted everything RO. Much complaining commenced as anyone who had run the script could no longer make any changes. ::)
Just thought I'd add that.
Steve
-
Enjoy:
https://github.com/bsdperimeter/pfsense/commit/7b2290139d7a52e2a77b76dcae6a524c1d959ecd -
Thanks Jimp, it works nicely.
My MO is to switch to RW before making a bunch of changes, then switch back to RO after the changes are done. Now this works from the GUI, no need to run the scripts from the command line. -
Thanks Jimp, it works nicely.
My MO is to switch to RW before making a bunch of changes, then switch back to RO after the changes are done. Now this works from the GUI, no need to run the scripts from the command line. -
works great, mine set to rw permanent, is there any issues setting it to rw permanent as i use only the cron package, the rest is all pfsense only?
-
Hard to say for sure, for a while there was a bug that was leaving it rw completely and people barely noticed. But there is always the risk that something will try (and succeed) to write to the media then.
-
bandwidthd is one offender that does not seem to have been modified to work correctly on nanobsd. If the filesystem is RO, it dies trying to write its output. If the filesystem is accidentally (or now purposely) RW, then it gleefully scribbles frequently to the CF card. I think I killed a CF card on a system that ran like this for a long time.
There were some issues with other packages that had bugs that left things RW under various conditions - I fixed up ones that I knew about.
The last issue I know about now is at bootup - with multiple OpenVPN servers and/or clients the bootup can run out of real memory on a 256MB nanoBSD system. In that case rc.bootup does not exit nicely and misses doing the mount RO. As long as you don't have wayward packages, it should not really matter.
The good thing is that you can now see on the dashboard if your file system is RW, and easily put it back to RO. -
Ah, does the widget read the filesystem or just the setting?
Steve
-
Ah, does the widget read the filesystem or just the setting?
It reads the filesystem. The same logic as the test on Diag > NanoBSD that lists the current status of the fs
-
Thanks Jim.
-
This is more than sexy! Thanks a lot! (Very helpfull in my situation because of reconfiguring 17 different VLAN's including rules :D)
Cheers,
Szop -
I wanted to try 2.1 (dec 07 snapshot) on my Alix box at home and unfortunately I have this issue when saving changes. I have a generic, no brand 4GB CF card.
I tried the workaround of switching to RW before making changes and it seems to work much better.
