[talk] ZFS v UFS on APU2 msata SSD with FreeBSD

Edward Capriolo edlinuxguru at gmail.com
Sun Jun 2 11:17:30 EDT 2019


On Saturday, June 1, 2019, Jim Thompson <jim at netgate.com> wrote:

>
> Beyond ZFS, you might have a look at boot environments.  Alan Jude has
> given some great talks about this at recent conferences (and accomplished a
> lot of the work behind the talks, of course).
>
> https://fosdem.org/2019/schedule/event/zfs_powered_
> magic_upgrades/attachments/slides/3340/export/events/
> attachments/zfs_powered_magic_upgrades/slides/3340/ZFS_Magic_Upgrades.pdf
>
> https://www.youtube.com/watch?v=YcdFln0vO4U
> <https://m.youtube.com/watch?v=YcdFln0vO4U>
>
> We’re investigating ZFS with boot environment as an idea for a future
> version of pfsense, with the APU2 and small ARM64 systems as the base
> (smallest) target.
>
> With boot environments we can roll forwards or backwards to any release
> that’s been installed, and not removed. Boot environments also don’t
> require us to waste space by creating disk partitions, so, even on an 8GB
> flash we could easily have 20-30 upgrade points, depending again on how
> much has changed between releases.
>
> If every single bit changed, (which is unlikely), we could only
> accommodate 8GB/N versions of the system, but, even so, we’d still have a
> much more flexible system to work with because of the preservation of
> history and the labeling of the snapshots (releases).
>
> The experiments on systems as small as 8GB “storage”/4GB “RAM” have panned
> out thusfar.
>
> Jim
>
>
One thing to note.
Once I was at a large company that loved their bad. It was the best
operating system EVR. It was also "so much faster then linux'.

So for argument sake. I made a test.

Tar -xf apache-http.tar.gz
cd apache *
./configure && make && make install

It took much longer in free bsd.
One key reason was that for ufs stock untarring Apache took about 40
seconds. (1ms with stock redhat ext3)

This was related to (dont quote me on this) the fact that all metadat
operations are synchronous and when unpacking something with a lot of tiny
files it was very noticable.

Apparently the cure was enabling soft updates (or something) but at that
point I lost interest because I was unwilling to get into a holy war with
'fanboy' sysadmins that had failed to notice that after working with free
bsd for like 10 years that it takes 40 seconds to unpack a tar file.

Anyway that even gave me a bias. I equated ufs to fat16. Great to boot on
(store 30ish never changing files) but not something I want to store any
application data on. I will happily run xfs zfs or ext4.

Note also at that time we had a few outages and when ufs came up we had to
choose. That was odd to. I have ext3/4 nix laptops that run out of power
while compiling or whatever. Sometimes they do come up without recent
changes , but they never come up unclean. When I was logging into those ufs
machines over an ilo yo run chkdisk I felt like I was living in a time
warp, like AOL still sending me floppies in the mail. Why did a fs so
"synchronous" that it takes 40 seconds to unpack a tar come up unclear so
often.


-- 
Sorry this was sent from mobile. Will do less grammar and spell check than
usual.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org:8080/pipermail/talk/attachments/20190602/40b8b48b/attachment.html>


More information about the talk mailing list