krondor

Excellent, not sure what I missed before, but I have aptx and aac now! A good step in the right direction. Still would love LDAC and/or Aptx HD of course in the long run.

Thanks, it looks similar to what I've tried so far. I'll give it another run through and see if I missed something.

No, I meant AAC. The XM3s do not seem to negotiate AAC over BT on OSX. They fall back to SBC and obviously sound bad. AAC would be a step up, but AptX HD or LDAC would be ideal. They work fine in my case on both iPhone and Android.

So as I was saying I'm tempted to move back to Linux for my work laptop for LDAC over BT support as well as other reasons of course.

I'm not sure about FreeNAS, but I do want to point out this is possible in the btrfs filesystem (sharded raid across drives). I'm not aware of any FreeNAS equivalents though utilizing it, but rolling your own is certainly an option.

Thank you, this was a great reply. Reading the discussions have been interesting.

Canonical is doing so anyway and it seems they have a legal disagreement on the interpretation of the law with the Software Freedom Conservancy.

IANAL so I have no clue what is technically correct, but the fact is that Ubuntu is distributing zfs.ko in 16.04.

Yes, apologies, I did mean lzo. zlib seemed perhaps too much on the CPU side of the IO/CPU calculation. I am excited to see how btrfs snappy and lz4 support compares when they are added, however.

To the point of lzo performance though, btrfs is a tad smart with compression, it tries to compress an initial 128KiB and if the compressed segment is not smaller than the uncompressed it adds it to a list of no compress files, and will not try compression on that file again (unless of course you force it).

This was for our Hadoop use case, comparing to ext4, so nodatacow would work because we have no desire of snapshots in that environment. It still seems like we're better of compressing within the Hadoop framework (as jamesblonde is doing) and sticking with ext4 jbod, for now at least.

Btrfs is not beta, see the discussion re: maturity below.

ZFS is an excellent filesystem, btrfs is an excellent filesystem. There is room for both excellent options for users.

I'm going to disagree with you re: compression. Compression at the FS layer brings a lot of benefits, and generally most workloads are IO constrained not CPU constrained. Compression at the FS improves IO at the expense of CPU.

Hadoop is a completely different workload, and maybe not something for ZFS or btrfs. Our Hadoop nodes are not raid, just JBOD ext4 disks. We have been conidering btrfs with nodatacow mount option and lz4 compression, however. We haven't decided if it's better to compress within Hadoop or at the fs layer yet. I would be curious on your findings.