I think that ship sailed when Microsoft started contributing code to the Linux kernel, although they had released lots of code under OSI-approved licenses way before that.

I once checked out the TV section of a Yodobashi Camera (and if you're ever in Japan, you really must visit a Yodobashi Camera, it's like every store of the floor is the size one or two BestBuy stores, except there's half a dozen floors or more). The brands of TVs on offer was very different from what you'd see outside of Japan. In most of the world, Korean brands like Samsung and LG are quite popular, but in that TV section (of what are probably the largest electronics stores in Japan), there was not a single non-Japanese television brand to be seen. Not a single Samsung or LG television was available.

- The difference is irrelevant, the apps are stored as platform-independent bytecode that (as of the next Android release) is then converted to machine code by ART or done on-the-fly by Dalvik itself. As a result, so long as Dalvik or ART supports the processor architecture, the application doesn't need to.

- As long as the ARM app doesn't use NEON (which I believe Intel's Houdini emulator doesn't support), it shouldn't have any problems running the ARM code on the x86 devices. In fact, you're likely to have better compatibility running emulated on x86 than you are natively on some older ARM devices.

You're accounting only for full-drive failures. IIRC BackBlaze indicates failure rates are higher than 5% per year, but that's not really relevant. The bigger problem is a read error during a resilver. That's something that the drive specs indicate should be expected at least once during any resilver, although in practice I find it less likely than that.

If you're using mirrored pairs, any resilver is (by spec) highly likely to result in corruption due to unrecoverable read errors due to lack of redundancy. Resilvering a single drive in a raidz2 array, however, still provides you with redundancy to recover from any read errors.

Yes, but write throughput is still increased, and not everybody needs more write IOPS. Furthermore, even with 8 disks you can build two raidz2 arrays and put them in a pool, at which point you've got the IOPS of two disks. And on top of that, you can use fast SSDs as ZIL cache devices.

Some points here:

- Most Android apps are Java bytecode, not native code, so the underlying processor architecture is irrelevant (for those apps)
- x86 is a supported Android platform, so many apps that do require native code have x86 binaries available
- Intel provides an ARM emulator for the x86 version of Android so that x86 Android devices can run ARM binaries
- Some ChromeOS devices use ARM processors to begin with.

Only if ZFS is communicating with that higher level. A simpler solution is to just use ZFS's native RAID instead of treating a RAID array as a block device. I can't think of a single benefit to doing that, but I can think of lots of reasons why it's a bad idea.

Sorry, brain fart. I meant "DEDUPE consumes insane amounts of RAM", not "BSD".

You shouldn't have to reinstall ZFS after any updates (apart from maybe a distro release upgrade, which on a file server running Ubuntu are probably being done every two years, or six months if you live on the edge), as it uses DKMS and will recompile the modules when you update the kernel or zfs.

Intel's best kept secret is that many of Intel's cheapest processors support ECC (including most of the i3 series), and as such enable you to build some surprisingly low-cost low-power file servers.

Here's the list of Intel desktop CPUs that support ECC:

http://ark.intel.com/search/ad...

Looks like the MSRP starts at $64 or so. The downside is that you need a chipset that supports ECC too, and those are only server chipsets. Luckily, a motherboard with one of those (like the Intel C222 chipset) start at ~$140 or so.

Slapping together a low-end server motherboard with an i3, some 8-drive HBAs, and a bunch of ECC RAM, it's a popular way to make a low-end file server.

It works if and only if the target system is also using LSI RAID controllers.

Meanwhile, I created my storage pool on Solaris UNIX, used it for years, then switched to Linux without having to do anything to the pool except "zpool export tank" on the old OS and "zpool import tank" on the new one.

Why would you run ZFS on top of two raid6 arrays instead of building a storage pool consisting of two 10-drive raidz2 vdevs? By doing what you're doing, you're effectively running with no redundancy despite being on top of raid6. If ZFS finds a checksum error, it thinks it's running on two big drives in a stripe with no redundancy, and it will be unable to recover the lost data.

What you're doing is highly inadvisable.

Since you shouldn't have more than 8 to 10 disks in any one raidz vdev, the suggestion that raidz is only for huge numbers of disks is absurd. If you're using more drives than that, you're going to be adding multiple vdevs to a pool anyhow, which is striping, so roughly equivalent to raid 5+0.

ZFS only supports on-the-fly dedupe. For batch dedupe, you're probably thinking of HAMMER in DragonFly BSD.

BSD consumes insane amounts of RAM and has a massive performance penalty. It's almost never worth it, because the cost of extra RAM will be more than if you had just bought more disks in the first place.

Compression, on the other hand, requires very little RAM or CPU resources, gives a tangible performance improvement, and saves space. Once ZFS implemented LZ4 (which is extremely fast) it begun making sense to simply always enable compression globally on every filesystem. They should probably make it enabled by default.

You're assuming that the single process isn't multithreaded. ZFS is multithreaded.