Updated today to latest snap - very 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. -
As another data point to eliminate… Tried two different thing:
1. Enabled write caching
2. Switched the underlying fs from UFS to UFS2Neither made any improvements in speed.
-
Ermal committed this patch https://github.com/bsdperimeter/pfsense-tools/commit/008742971cb44d8c0f81929504ab7330442c4ba4 and I would really like to try it out. For some reason it is 16 hours now and no new snapshot has appeared. Is there a problem with the snapshot builder making this? Or will I find that a new snapshot appears 5 minutes after I post this?
I have a nanobsd Alix system that I am currently setting up that exhibits all the symptoms and it is easy for me to upgrade and test.
Edit: I see Jimp just bumped 2.1 to BETA1 - maybe that is a sign that this long-standing nanobsd issue is fixed. -
working on getting the ports up to date on the snapshot builder. We've had a few fixes in pfPorts lately and freebsd bumped some versions in things like pcre, so I'm trying to get everything building happily yet.
His fix does work, I have a card here that was taking ~40s to switch back and now it's under 1s. It'll just be a few more hours until the snaps are going again.
