Wandering Thoughts archives


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.

tech/ZFSWhyILikeIt written at 23:27:21; Add Comment

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.)

unix/FreeBSDvsLinux written at 01:31:40; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.