Updated today to latest snap - very slow
-
re-flashed today to latest snap… still extremely slow, when re-mounting as ro
Btw, my CF is a Lexar 4GB if it matters.. are there any logs that may shed some light?
-
To add a couple more data points:
- Enabling TRIM on the slice - no effect, still slow
- Enabling softupdates on the slice - no effect, still slow
- Running sync;sync;sync; before mounting ro - no effect, still slow
- The mount process sticks in biowr state, which is disk i/o
- While mount is stuck, the system is somewhat unresponsive - can't run a process or connect with ssh, but does appear to continue routing.
-
I went ahead and opened a redmine ticket for this:
https://redmine.pfsense.org/issues/2401 -
…
Many have also suggested that there's a difference in behaviour between an upgrade an a fresh install of the flash card. I doubt it actually has any impact, but I'll run that test tomorrow on the cheapo card to eliminate/confirm it.
- Mark
As expected, the slow CF card still exhibits stalls in mount rw -> ro irrespective of whether the image is an upgrade or a complete reimage of the flash.
As far as I can remember, my slow CF card can be written at just under 4 MB/s from the dev virtual machine. The sandisk card by comparison writes at over 5MB/s.
- Mark
Within half an hour of putting the 4801 in production with a sandisk 8G card instead of the previous slower 4G card, the system started exhibiting "stall" conditions.
Unfortunately, my production placement makes serial access a pain (and hence kernel debugger) so I haven't garnered much since.
I'm at the point where I'm thinking I'll just rebuild the kernel and use unionfs to reduce flash wear and tear and do the occasional sync to either underlaying fs or a persistent overlay.
- Mark
-
I went ahead and opened a redmine ticket for this:
https://redmine.pfsense.org/issues/2401Here's a bit more detail for what you described. The fact that flushfiles is flushing out so much on a quiescent filesystem is rather suspect (as a counter point, run lsof and look for writeable files).
The next line is a tty interrogation with ^T
load: 0.22 cmd: mount 2123 [biowr] 5.82r 0.02u 0.08s 7% 1044kThis is the alternate ddb entry, "~^b"
~KDB: enter: Break sequence on console
-
So…. has this been abandoned or still actively looked into?
Weekend coming up, have time for testing :-D
-
It hasn't been forgotten, but I haven't had any new leads to try. Ermal thought it might be something that was recently fixed on FreeBSD 8-STABLE, but I wasn't able to make usable patches out of the commits I found so for me that was a dead end (someone else might give it a try)
-
Any (good) News? :)
-
None yet
-
It seems that the bug still exist interface is very slow unless I execute /etc/rc.conf_mount_rw in ssh. So workaround is to run /etc/rc.conf_mount_rw before making any changes
-
We're still aware it's an issue, there is an open bug in redmine for it.
-
I noticed that Seth Mos has committed "Hopefully tackle the slow nanobsd writes. Redmine ticket #2401" on Github. I guess this is probably built in the version I just updated to:
2.1-BETA0 (i386)
built on Tue Jun 19 20:53:01 EDT 2012
FreeBSD 8.3-RELEASE-p3Is there any particular sequence of operations that we can/should test to help to see if the issue is resolved or improved?
(I must say, I haven't really noticed the issue on various test nanoBSD installs on my Alix 2D3 in recent weeks!) -
It didn't help, unfortunately.
Timing the mount rw then ro calls is sufficient, see the existing redmine ticket for it.
-
Just installed snapshot pfSense-2.1-DEVELOPMENT-2g-i386-nanobsd-20120629-1927
still the same problem -
Same here … had no problems with 2.0.X on my alix. After upgrading to 2.1 about 1 month ago WebGUI is very slow from that point, especially when making changes. After upgrading to latest snapshot and reboot now i'd to restart Webconfigurator via console to have access to my pfSense. I hope the issue can be solved in 2.1, cause i have many alix boards out at customers and this behavior would prevent me to upgrade these boxes ...
-
I also noticed that on recent updates (I think from the beginning of July), after the install reboot, I have to use the console to restart the web configurator. Reboots after that have been fine. So something is happening on the first reboot (of course it reinstalls packages at that time, but that should not kill the web configurator). This web configurator restart issue is probably a different thing to the slow RW mounting. I have also had other web configurator issues recently - see http://forum.pfsense.org/index.php/topic,51188.0.html - maybe there is some common issue here in a recent build that is effecting the web configurator?
-
Any news on that? I've updated yesterday to 2.1-BETA0 (i386) built on Thu Oct 11 and having the sames issues like described by you all. The GUI is very fast but when I have to do some changes or for example creating a new OpenVPN account, I have to wait like 1-2 minutes until one step finishes. I'm running on nanobsd (4g).
Cheers,
Szop -
Any news on that? I've updated yesterday to 2.1-BETA0 (i386) built on Thu Oct 11 and having the sames issues like described by you all. The GUI is very fast but when I have to do some changes or for example creating a new OpenVPN account, I have to wait like 1-2 minutes until one step finishes. I'm running on nanobsd (4g).
Cheers,
Szopthe bug report is still open, no progress on it as of now, seems something from freebsd
-
Okay, thanks for the fast reply. Can you provide me a link to the bug report?
Cheers,
Szop -
