Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)

[George Michaelson <ggm@algebras.org>]

snapshots of FS state existed for years before ZFS/BTRFS did it,
because FS journaling existed. The underlying model of COW forking of
the inodes and a journal were all there.

What ZFS did, and what Docker does, and snap does, and flatpack does,
is package things in a way which make modalities for use for  modern
sysadmin "just work"

I don't recall seeing a backup model built on UFS+journalling with an
integrated command tooling to do what zfs snapshot; zfs send | zfs
receive does as an incremental copy mechanism. I'm not trying to
disrespect the prior art, if there was a good packaging, I probably
missed it. ZFS made this "yea, I get it now" for a lot of people.

I think ZFS is fine. I have adopted it wholesale in the work context
for the last 15+ years and at home for about a year. The FUD around
minimum memory for ARC is a misunderstanding of an Oracle document
"back then" and you can run ZFS on rPi class systems fine, if you can
accept some lumpy paging and VM behaviour, and if you don't enable
compression which burns the ARC. (you need the extent of memory to
deal with things a lot more) -And there are modern OpenZFS docs which
patiently explain this stuff.

Zsys is going to get better. This means rollback from systems update
under Ubuntu snaps and things, will get better. It will be a lot less
risky to do significant upgrade on systems. -Think about Android and
the two-root model of updating the passive root in the background, so
the new OS is live across a reboot without having the spinning
beachball of upgrade on your phone, or analogues of the "keep this
setting or go back" model WIndows does, and Windows has had OS
snapshots for a long time now, and offers "undo that major update"
models to users: people expect this.

I also think ZFS was a godsend for getting over the smart RAID card
mistakes of the past. I HAVE lost data with these puppies. I've moved
multi TB fs between FreeBSD and Linux and back again (with care) under
ZFS, and you can't do that with Apples FS, or EXT3 with anything like
the same confidence.

Really? I like UUID. UUID are a godsend, for making things have
unique,  but asynchronously generated identity, so when you move them
and mix them, you can stop worrying about device/bus order and simply
re-create them as they were defined semantically. ZFS does this too:
zfs import is leveraging what UUID does for you.

Basically Larry, I think you are kindof wrong. These alumni of yours
did what all kids should do: they ran ahead. Did they scrape their
knees doing it? Sure. But if they don't try things their teachers say
are bad, how do they advance the art? If we'd listened to Eddy
Dijkstra, we'd never have got BGP: He said it couldn't scale, even
though it was based on his own work.

-G

On Fri, Feb 5, 2021 at 4:41 AM Bakul Shah <bakul@iitbombay.org> wrote:
>
> On Feb 4, 2021, at 8:34 AM, Dan Cross <crossd@gmail.com> wrote:
> >
> > On the other hand, if we're discussing OS design and implementation, (re)splitting the VM and buffer caches is a poor decision. One might well ask, "why?" and the answer may be, "because it adds significant complexity to the kernel." This to me seems like the crux of the disagreement. Satisfied users of ZFS might legitimately ask, "who cares?" and one might respond, "kernel maintainers." If the kernel is mostly transparent as far as a particular use case goes, though, then I can see why one would bulk at the suggestion that this matters. If one is concerned with the design and implementation of kernels, I could see why one would care very much.
>
> Largely agree; though the complexity battle has long been lost. On multiple fronts. Many of us are happy to use such complex systems for their ease of use or their feature set but wouldn’t want to maintain these systems!
>
> I have used ZFS since 2005 and largely happy with it. Replaced all the disks twice. Moved the same set of disks to a new machine. etc. Features: cheap and fast snapshots, send/receive, clone, adding disks, checksummed blocks, redundancy etc. The dedup impl. is suboptimal so I don't use it. No idea if they considered using a bloom filter and a cache to reduce memory use. If a new FS came along with a similar set of features and a simpler, better integrated implementation, I'd switch.
>
>