2014-07-30
Why I like ZFS in general
Over time I've come around to really liking ZFS, not just in the context of our fileservers and our experiences with them but in general. There are two reasons for this.
The first is that when left to myself the data storage model I gravitate to is a changeable collection of filesystems without permanently fixed sizes that are layered on top of a chunk of mirrored storage. I believe I've been doing this since before I ran into ZFS because it's just the right and simple way: I don't have to try to predict how many filesystems I need in advance or how big they all have to be, and managing my mirrored storage in one big chunk instead of a chunk per filesystem is just easier. ZFS is far from the only implementation of this abstract model but it's an extremely simple and easy to use take on it, probably about as simple to use as you can get. And it's one set of software to deal with the whole stack of operations, instead of two or three.
(In Linux, for example, I do this with filesystems in LVM on top of software RAID mirrors. Each of these bits works well but there are three different sets of software involved and any number of multi-step operations to, say, start using larger replacement disks.)
The second is that as time goes by I've become increasingly concerned about both the possibility of quiet bitrot in data that I personally care about and the possibility of losing all of my data from a combination of a drive failure plus bad spots on the remaining drive. Noticing quiet bitrot takes filesystem checksums; recovering from various failure modes takes deep hooks into the RAID layer. ZFS has both and thus deals solidly with both failure possibilities, which is quite reassuring.
(ZFS also has its own fragilities, but let's pretend that software is perfect for the moment. And any theoretical fragilities have not bit me yet.)
As far as I know there is no practical competitor for ZFS in this space today (for simple single-machine setups), especially if you require it to be free or open source. The closest is btrfs but I've come to think that btrfs is doing it wrong on top of its immaturity.
My view on FreeBSD versus Linux, primarily on the desktop
Today I wound up saying on Twitter:
@thatcks: @devbeard I have a pile of reasons I'm not enthused about FreeBSD, especially as a desktop with X and so on. So that's not really an option.
I got asked about this on Twitter and since my views do not in any way fit into 140 characters, it's time for an entry.
I can split my views up into three broad categories: pragmatic, technical, and broadly cultural and social. The pragmatic reasons are the simplest ones and boil down to that Linux is the dominant open source Unix. People develop software for Linux first and everything else second, if at all. This is extremely visible for an X desktop (the X server and all modern desktops are developed and available first on Linux) but extends far beyond that; Go, for example, was first available on Linux and later ported to FreeBSD. Frankly I like having a wide selection of software that works without hassles and often comes pre-packaged, and generally not having to worry if something will run on my OS if it runs on Unix at all. FreeBSD may be more pure and minimal here but as I've put it before, I'm not a Unix purist. In short, running FreeBSD in general usage generally means taking on a certain amount of extra pain and doing without a certain amount of things.
On the technical side I feel that Linux and Linux distributions
have made genuinely better choices in many areas, although I'm
somewhat hampered by a lack of deep exposure to FreeBSD. For example,
I would argue that modern .deb and RPM Linux package management is
almost certainly significantly more advanced than FreeBSD ports.
As another one, I happen to think that systemd is the best Unix
init system currently available
with a lot of things it really gets right,
although it is not perfect. There are also a horde of packaging
decisions like /etc/cron.d
that matter to system administrators
because they make our lives easier.
(And yes, FreeBSD has sometimes made better technical choices than Linux. I just think that there have been fewer of them.)
On the social and cultural side, well, I cannot put it nicely so I will put it bluntly: I have wound up feeling that FreeBSD is part of the conservative Unix axis that worships at the altar of UCB BSD, System V, and V7. This is not required by its niche as the non-Linux Unix but that situation certainly doesn't hurt; a non-Linux Unix is naturally attractive to people who don't like Linux's reinvention, ahistoricality, and brash cultural attitudes. I am not fond of this conservatism because I strongly believe that Unix needs to grow and change and that this necessarily requires experimentation, a willingness to have failed experiments, and above all a willingness to change.
This is a somewhat complex thing because I don't object to a Unix
being slow moving. There is certainly a useful ecological niche for
a cautious Unix that lets other people play pioneer and then adopts
the ideas that have proven to be good ones (and Linux's willingness
to adopt new things creates churn; just ask all of the people who
ported their init scripts to Upstart and will now be re-porting
them to systemd). If I was confident that FreeBSD was just waiting
to adopt the good bits, that would be one thing. But as an outsider
I haven't been left with that feeling; instead my brushing contacts
have left me with more the view that FreeBSD has an aspect of
dogmatic, 'this is how UCB BSD does it' conservatism to it. Part
of this is based on FreeBSD still not adopting good ideas that are
by now solidly proven (such as, well, /etc/cron.d
as one small
example).
This is also the area where my cultural bad blood with FreeBSD comes into play. Among other more direct things, I'm probably somewhat biased towards seeing FreeBSD as more conservative than it actually is and I likely don't give FreeBSD the benefit of the doubt when it does something (or doesn't do something) that I think of as hidebound.
None of this makes FreeBSD a bad Unix. Let me say it plainly: FreeBSD is a perfectly acceptable Unix in general. It is just not a Unix that I feel any particular enthusiasm for and thus not something I'm inclined to use without a compelling reason. My default Unix today is Linux.
(It would take a compelling reason to move me to FreeBSD instead of merely somewhere where FreeBSD is a bit better because of the costs of inevitable differences.)