Full Install: Select Partition Type
-
Is this true across the board? My SG units have not had SU enabled on the mSATA drives.
I'll admit I haven't payed enough attention to this…
I rather won't comment on UFS SU+J, it's currently the ONLY choice on full installs.
It gets turned on at install time. If it's been upgraded that won't change.
-
Is this true across the board? My SG units have not had SU enabled on the mSATA drives.
SU+J was introduced on 2.2.3 to "fix" the filesystem corruption. If your install is older, you won't have it, and frankly you are not missing out on anything. It did not help at all with the original issues and made completely kaboom on embedded where it was reverted in 2.2.4.
It wasn't used as a fix for the corruption it was used to lessen the fallout. Without SU+J the files were corrupted (had other file contents inside) with SU+J they were truncated to 0 bytes, which was safer. Though the real problems that caused the corruption have now been solved on 2.2.4, SU+J is still more reliable in the long term now.
-
-
SU+J is still more reliable in the long term now.
We'll agree to disagree… :P
Well you're right it was a bad move for NanoBSD, but for full installs it's been good. :-)
-
Well, as said above… Dunno, did someone move the unusable fsck issue upstream? B/c I somehow got the impression that the fsck handling after the shitload of related commits now pretty much matches upstream FreeBSD -- and still cannot see how such behaviour is usable on remotely administered boxes.
-
It wasn't used as a fix for the corruption it was used to lessen the fallout. Without SU+J the files were corrupted (had other file contents inside) with SU+J they were truncated to 0 bytes, which was safer. Though the real problems that caused the corruption have now been solved on 2.2.4, SU+J is still more reliable in the long term now.
I got totally unusable instance 100 kms away after serie of power outages. It was 2.2.3.
I was able to restore config (using "remote arms" of my non IT colleagues), but is just answering pings. Nor WEB, nor ssh could be used to manage it.
As it was on picture ther sent - it was with zero config after power recovery, no WAN\LAN defined, nothing.So what is best strategy to avoid corruptions? I am going to force "fsck -y" every time it boots.
-
Best strategy is to run 2.2.4, 2.2.3 didn't have complete fixes for the problems. 2.2.4 has fixes for the passwd/group issue as well as times when the config.xml could be zero/empty.
-
If the unit is on a UPS, wouldn't SU be preferable to SU+J? Particularly for flash based storage (mSATA)?
-
Asking it a different way… What is the advantage of SU+J over SU with pfSense?
-
If there was a working fsck, the journaling would help with some cases of unclean unmount/hard reset. Sadly, the fsck is totally borked and produces a giant kaboom in that case. So, from my POV, there is absolutely no advantage whatsoever.
https://redmine.pfsense.org/issues/4822
-
If there was a working fsck, the journaling would help with some cases of unclean unmount/hard reset. Sadly, the fsck is totally borked and produces a giant kaboom in that case.
Only with crap flash (though it's certainly very bad in that case). On a SanDisk CF in an ALIX, and a SanDisk SD in an APU, they survived a thousand power cycles each left rw mounted, SU+J, with some writing happening when power was lost.
I took an affected CF card that fsck couldn't fix, dd'ed it to an img and booted it up in KVM, and fsck cleaned it just fine. Same when dd'ing it to another CF, was fine. Something screwy going on there with the problem flash, but didn't bother digging any further after confirming it doesn't happen minus SU+J.
