One way to exceed the write capacity of the HDD is to compress the data before it hits the disk. ZFS supports transparent compression using such algorithms as lzjb, gzip, zle, lz4. The lz4, in particular, is quite a fast algorithm. From the man pages:while PC-BSD 10.0 was much faster... Too fast, in fact. The reported speeds were past where the Fujitsu HDD is capable of performing so it looks like there's some handling of ZFS in PC-BSD where not all operating may be writing to the disk as handled in previous releases or other changes with syncing to the disk or caching.
The lz4 compression algorithm is a high-performance replacement for
the lzjb algorithm. It features significantly faster compression and
decompression, as well as a moderately higher compression ratio than
lzjb, but can only be used on pools with the lz4_compress feature set
to enabled. See zpool-features(7) for details on ZFS feature flags
and the lz4_compress feature.I am curious as to the basis of this claim, or is this mealy an supposition. ZFS has been specifically designed to handle hardware failure (i.e. a flip bit), and thus I expect a power failure will be easily managed as ZFS, using hashes of all data including meta data, will simply discard the bad data and work off a previous state. I cannot, however, provide any links to substantiate my expectation.It can deliver faster results but it's unsafe in the case of power outages or other issues if the disk is left in an awkward state.
Debian GNU/kFreeBSD jessie could be interesting once the FreeBSD 10.0 kernel is ready, due to generally still using GCC 4.8 (same as Ubuntu).
Same as the results in 2010, Linux still beats crappy BSDs overall.