For the record, I also think it's cool to get this compiled and running on RasPi; just wanted to add the ECC info for anyone now thinking of doing something with this in production :-D.
See a quote from Matt(hew) Ahrens (zfs developer)[0]:
There's nothing special about ZFS that requires/encourages the use
of ECC RAM more so than any other filesystem. [...] I would simply
say: if you love your data, use ECC RAM. Additionally, use a
filesystem that checksums your data, such as ZFS.
The Raspberry-Pi can't perform that good because it lacks USB-3 or something else with good performance (it only has USB-2)... It is not a very good choice for a file server. The ODROID-XU4 seems like a much better choice even if it is double the price.
You're probably thinking of deduplication (whose memory requirements is ~320 bytes per deduplicated block, and which generally requires way more than 1GB per TB, it's highly variable depending on storage load but I've seen quotes from 5 to 20GB/TB). Most users don't benefit from deduplication and it's usually recommended not to enable it unless you do demonstrably get large benefits from it (on FreeBSD, `zdb -S` will simulate and estimate deduplication benefits).
1GB is the recommended conf for ZFS on FreeBSD, it will benefit from more (and may need some tuning below 2GB) but even that's not a requirement, the FreeBSD wiki's ZFS tuning page quotes "ZFS running nicely on a laptop with 768 Megs of physical RAM" with tuning (and provides configuration values).
I've always been wondering if file system RAM caches couldn't be moved to a fast SSD nowadays. Do you think this would be possible with, say, an Intel 750?
ZFS (and probably others) let you do that, kinda: it always has a primary in-memory cache but you can add level 2 cache devices (L2ARC) to the pool. In fact you can extend two different caches to storage devices: L2ARC is a read cache, and you can add a separate set of Log Devices used by the ZFS Intent Log, where writes are cached.
While I haven't tried crochet, I have tried building my own RPi-B+ image. You mention in your guide that you'll post updates "when you have something", and judging by your post it seems you have.
Since I had difficulties compiling the zfs (and one other, which I don't recall) module, I'm wondering if you'd care to share your experience in your guide?
Kudos to your very well thoughtout and thorough guide.
I got it going a few days ago, have been meaning to update the guide and post some images so people can skip the compilation. Star the repo for updates.
You're probably thinking of the opensolaris module. There's a small patch to apply and some KERNCONF to trigger the module build but otherwise its straightforward -- once you know where to look!
The title of this post -- "FreeBSD on the raspberry pi" -- is not very descriptive. The title seems to imply that running on the Raspberry Pi is news, which it's not, as myself or anyone else already running FreeBSD on our Pi can attest to. I'd suggest changing the title to "Patch posted to have FreeBSD use armv6hf target arch by default for the Raspberry Pi" -- however, someone just commented on the Pull Request:
>armv6 is already hard float, all armv6hf gives you is it will pass floating-point data to functions in floating-point registers. I also expect that armv6 will be using the hard float ABI soon (within a month) an at this time armv6hf will be removed.
OP here I agree with you it can be misleading into thinking that FreeBSD is _now_ available on the RPi which of course would be very misleading and simply untrue because FreeBSD on the RPi is nothing new. Reading the others comments, it's not misleading. Changing the title to what you have suggested would be nice for the FreeBSD devs mailing list and would not appeal to many people on HN. The point of the post is to draw attention to FreeBSD on the RPi and FreeBSD as it's really a great piece of software and__not__ to the patch itself. And I thing IMHO that the RPi can be great a great vector to enlarge the user base of FreeBSD with all the benefits that this can bring to the project.
My biggest problem with fbsd in the rpi is that it's really hard to cross-compile ports for arm, and compiling everything in the rpi takes a lot of time (I think it was half a day to compile tmux in the rpi A).
The Netgate RCC-DFF 2220 is available[1] right now, and performs very well as a BSD router. It's not ARM, but it is an embedded system/SBC. I use it with pfSense, but it will run vanilla FreeBSD as well of course.
But no pretty Web UI. And Im pretty sure FreeBSD will not use the possibly existing network acceleration instructions that exists for example in the oceton soc.
Obviously you think it's a waste of time- the burden is on you to explain why not. Not why you don't work on it yourself, but why you think people who are working on it shouldn't be.
I think it's a completely fair thing to politely ask why people are spending their time on this. Surely they have somg goal in mind.. Maybe they have some bigger goal, like commercial OS's tuned to the RPi or something that only BSD systems can do? Or maybe it's something simpler
I talk to people who can't understand why I spend exorbitant amounts of money on my Harley or jump on it and ride for hours ever chance I get, only to end up right back at home, where I started.
My girlfriend doesn't understand why I spend so much time in my office typing white letters into a big black box.
I don't understand why some people spend large amounts of their {money,free time} collecting stamps or coins or playing golf. To me, all of these things are boring as hell.
In each of these cases, however, there's no need to (have to) explain why. Any answer (including "because it makes me happy" or "because I want to") is completely valid and acceptable.
Of course that's a fair thing to ask, but that post wasn't asking that question. That post wasn't asking a question at all, it was clearly intended as an insulting statement in the form of a question.
I think there is an implied frustration with the fragmentation of "the open source effort", which is ... understandable. It should have been written more diplomatically. It seems to me to be a pervasive problem on anonymous forums.
I wrote up a guide: https://github.com/hughobrien/zfs-remote-mirror