Compressed mfsroot vs. not vs. FreeSBIE hybrid
-
Ok next problem, the root file system.
FreeNAS uses a big mfsroot file. Which is the same as flashboot for OpenBSD.
Flashdist for OpenBSD has the complete filesystem raw.
FreeSBIE and pfSense have a strange compromise of only /usr UZIPed, everything else is raw, albeit /etc and /var mounted in tmpfs.
Whats the deelio behind this? Which is better, which should I follow? I'm presuming some thought, discussion, and notes are available on this? I'm currently testing ISO, and HDD install, I need to pickup another serial cable to actually test on WRAP hardware. The benefit of the compressed mfsroot was smaller on disk size for flash, and easy upgrades.
-
We chose the method we have now for a number of reasons:
1. People sometimes like to alter their image without touching their toes, jumping through hoops and burping at the same time. A MFS requires just that.
2. We will be using binary diff updates on the next release. Let's see you make a MFS and Binary Diff Updates work in tandem.
3. Having a un-needed ram disk on embedded is silly IMHO. A simple RO mount of the partition works fine.
-
1. People sometimes like to alter their image without touching their toes, jumping through hoops and burping at the same time. A MFS requires just that.
I had notcied :(
2. We will be using binary diff updates on the next release. Let's see you make a MFS and Binary Diff Updates work in tandem.
I saw this in CVS, there definetly needs to be a way of updating without wiping out the entire image. For pfSense you need to keep captive portal pages, and for the directory server a stash of tftp files.
3. Having a un-needed ram disk on embedded is silly IMHO. A simple RO mount of the partition works fine.
I cannot remember from my degree but google research says that flash has significantly higher read lifetime than write lifetime. Together with 512MB flash available for US$10 the saving of disk space is pretty much irrelevant, memory however is limited with no way of upgrading a WRAP box.
-
I saw this in CVS, there definetly needs to be a way of updating without wiping out the entire image. For pfSense you need to keep captive portal pages, and for the directory server a stash of tftp files.
These features have no idea of what they are stored on. If its embededded, hard disk, live cd, etc, each feature was designed to live across state changes.
I cannot remember from my degree but google research says that flash has significantly higher read lifetime than write lifetime. Together with 512MB flash available for US$10 the saving of disk space is pretty much irrelevant, memory however is limited with no way of upgrading a WRAP box.
Not sure what you mean by this but I have been working with embedded devices for a long time now and what you see in pfSense is what I have learned so far.
-
I'm having a problem with the /tmp partition not mounting from FreeSBIE, any ideas?
# /sbin/mdmfs -S -M -s 20m md /tmp mdmfs: newfs eited with error code 35 # /sbin/mdmfs -S -M -o async -s 16m md1 /tmp mdmfs: newfs eited with error code 35The /usr partition managed to mount successfully from UZIP though :o
-
Okie dokie, I think I found it using the -L parameter:
# /sbin/mdmfs -L -S -M -s 20m md /tmp /dev/md10: 20.0MB (20960 sectors) block size 16374, fragment size 2048 using 4 cylinder groups of 5.02MB, 321 blks, 704 inodes. super-block backups (for dsck -b #) at: 160, 10432, 20704, 30976 newfs: Cannot retrieve operator gid mdmfs: newfs exited with error code 35 -
Yup, my fault for using FreeNAS core. I can have a passwd & group file in /var/etc which is linked from /etc and when /var is mounted re-create as per normal. FreeNAS needs to modify passwd & group in order to support ftp and samba clients. But if /etc is mounted in mfs it is a rather redundant setup :D
-
I've been at this for a long while and I can tell you that FreeSBIE 2 is the absolute goodz. But then again I am a FreeSBIE commiter, so I am biased and know the code extremely well.