NanoBSD - 2.3.1_1, read/write, compact flash
-
Hi,
2.3.1_1 introduces a read/write only behavior for the NanoBSD line.
Historically, NanoBSD followed a read-only approach with some read-write behaviors for certain situations. As noted on this pfSense comparison page "Full Install and NanoBSD Comparison page", under NanoBSD section: https://doc.pfsense.org/index.php/Full_Install_and_NanoBSD_Comparison
"Disk is kept in a read only state to preserve the long-term life of the media, switches to read-write for configuration changes, package installation, etc, then changes back"
I have quite a few systems running on Compact Flash (CF) cards.
Should I be concerned now about their longevity?
-
"Disk is kept in a read only state to preserve the long-term life of the media, switches to read-write for configuration changes, package installation, etc, then changes back"
Yep, this is right.
I have quite a few systems running on Compact Flash (CF) cards.
Perhaps time to change them against newer hardware?
Since version 2.3 also the 1 GB and 2 GB images are gone, so it would be perhaps a nice
thing to change against USB tumb drives, or am I wrong with that? 2 USB pen drives once
with a installed pfSense version and the then copying over to the next one and if one is dying
you must only switch over to the other one! Better in my eyes, what do you think about?Should I be concerned now about their longevity?
No storage or drive lives forever! And so you could try out to stay at the version 2.2.6 that
will be perhaps not affected by that problem? -
First of all - I am a supporter of pfSense for 8 years, it's been a great platform for countless reasons. That said, I'd like to clarify some more my previous comments.
One of the values that pfSense always offered inherently was that it supported embedded hardware (ALIX/Soekris type of hardware) which can be significantly more powerful than your standard consumer home access point/router; pfSense was built based on best practices for embedded which made it reliable. For example, the discussion of NanoBSD - always having the default setting of read-only for the root file system. As I read: https://doc.pfsense.org/index.php/Installing_pfSense, it states:
An Embedded style installation is geared toward reduced writes on the filesystem, but also cannot run some of the more interesting available packages. A full install may be a little rougher on the target media, but is fully capable of using any packages and other features.
Is 2.3.x doing away with this idea based on more powerful hardware in general? I keep hearing this repeated theme of "upgrade your hardware" in the forums ever since the introduction of the 2.3.x release. I personally have not seen anything concrete as to why, so there's a huge gap between the understanding of embedded and "upgrade your hardware" I think for a lot of people. I mean - even a Soekris Net 5501 can support significant routing traffic for a small/medium sized business (not considering heavy things like Layer 7 filtering or Squid).
I took a look at the 2.3.1.x release notes regarding this topic:
NanoBSD is now permanent read-write, to avoid issues with slow rw->ro mount times and systems getting stuck read-only mounted.
https://redmine.pfsense.org/issues/6184
I made some quick tests with /etc/rc.conf_mount_ro and /etc/rc.conf_mount_rw.
I observed that switching to read-write from read-only had no lag.
I observed that switching from read-write to read-only produced a ~30 second lag.There were no indications from top that memory or CPU were consumed, actually dead silent.
So it's not clear at this point the technical problem but some quick looks around the internet about this problem with FreeBSD give some indication of a known problem.
Is there anything that the pfSense team can do to better understand this problem to maintain the intent of NanoBSD?
Or is NanoBSD dead? -
Or is NanoBSD dead?
No it is not dead, but since the mSATA and/or M.2 SSDs you are abel to do a fresh and full install
and also using packets like squid, Snort, SquidGuard, SARG, Suricata, pfBlockerNG and others that
are really popular. On top of this the mostly NanoBSD installs might be more running on USB pen
drives at this days. -
Still - without read-only, the USB pen drive could potentially suffer the same death as a compact flash media.
@BlueKobold:
Or is NanoBSD dead?
No it is not dead, but since the mSATA and/or M.2 SSDs you are abel to do a fresh and full install
and also using packets like squid, Snort, SquidGuard, SARG, Suricata, pfBlockerNG and others that
are really popular. On top of this the mostly NanoBSD installs might be more running on USB pen
drives at this days. -
As far as I know, the write cycles have been reduced drastically to not be a problem for CF cards and such.
Most of the volatile stuff is stored in memory (ram disk) with NanoBSD./tmp (ufs in RAM)
/var (ufs in RAM) -
Hi Jahonix,
That's helpful. If you know of any documentation that speaks to the reduction in writes… please point me. /tmp and /var being in RAM sounds logical.
Thanks,
As far as I know, the write cycles have been reduced drastically to not be a problem for CF cards and such.
Most of the volatile stuff is stored in memory (ram disk) with NanoBSD./tmp (ufs in RAM)
/var (ufs in RAM) -
Still - without read-only, the USB pen drive could potentially suffer the same death as a compact flash media.
Only as "read only" I was meaning on the usb pen drive.
-
If you know of any documentation that speaks to the reduction in writes… please point me.
Search the forum.
cmb or some other developer wrote about it here. I only remember having read it.
