The argument against allowing expansion of parity arrays is that if you find yourself wanting to add a single disk to a parity array, you didn't properly plan for expansion when you designed the system. ZFS was originally designed for enterprise customers, for whom that was not a feature that would rarely ever see use. It was not intended for the home user piecing together spare parts for a file server.

If you have RAID1 and add a drive, you still have RAID1, and just as much storage as you started with. You only add redundancy, unless you're saying it converted the mirror into a parity array.

On a gigabit network with the standard 64K pipe buffer, you'll trickle along at just a few megabit.

Chances are if you're an enterprise user running enterprise Linux with a support contract, you're going to engineer in immediate needs, future expansion, and replacement when you purchase your server equipment. You're not going to throw something together and get yourself into a situation where you would need dynamic resizing of a stripe. That's more a concern for the home and small business user who may not have the funds to plan for expansion when building a server, but then that's not the market Sun was shooting for when designing ZFS.

Why would I prefer DIF on FC and SAS2 over the drive's internal ECC mechanisms? A single layer of protection means a single layer that has to fail before data loss.

The same can be said for any other filesystem as well. If you have a bad bit in memory, and you write it to disk, that data is corrupted. The only penalty under ZFS is that if you gave it redundancy, and leave checksums enabled, it will detect that fault, try to correct it, and in doing so crush the whole block instead of just one bit.

If you aren't going to use ECC memory, don't use checksums either.

While you cannot add new drives to a vdev, you can expand a vdev by incrementally replacing all of its drives with larger versions. Replace a drive, resilver, replace a drive, resilver... and when you're all done, just export the pool, import it back, and you have the full capacity of the new drives available.

It appears to use a lot of memory because it replaces the standard kernel disk cache with its own ARC, and as unused memory is wasted memory, the ARC will eat up every last bit of memory you allow it.

It's performing a checksum of your entire system. That's going to be a CPU hog. BTRFS will be no different in this regard. Still, the default algorithm is fairly lightweight, and on a modern multi-core multi-GHz system, you should be bottlenecked on disk long before you "thrash" your CPU. If you're trying to run ZFS on an old low end Atom, well... don't do that!

Of course it does. It just has some limitations. You cannot remove devices from a pool, and you cannot reshape a Z/2/3 vdev. You can add a new disk to a mirror vdev. You can replace all the disks in a Z vdev with larger ones, and then expand the vdev to use the new space. You can add a new disk to a pool. You can add a new mirror or Z vdev to a pool.

If you intend to send the snapshots over the network, as is often the case with rsync, you need to pair it with some independent communication tool, and since the output of "zfs send" tends to be very bursty, you need a sizable memory buffer.

Do you hide them behind the finished carpentry projects?

More accurately, the "exciting" choice is the inexpensive choice, and inexpensive means more launches, or more money available for other programs.

This isn't the turn of the century with your new fangled AGP 4x graphics card. PCI Express is symmetric. You can pull data in from peripherals just as fast as you can push it out. If there is a bottleneck in pulling computed physics data from modern graphics cards, it's entirely the fault of the internal design of those modern graphics cards.

Did the satellite get delivered to its intended orbit? Then it's a successful launch. That makes twelve successful launches, one partial success (primary delivered, secondary failed), and three failures.

You're not trying to find submarines hiding on the other side of a thermocline. You're just trying to track any obstructions within a couple dozen feet.

So give the thing a low power sonar system and automatic collision avoidance system. Give it instructions that if the battery gets below a certain point, it shuts down the engines, auto-surfaces, and starts up a rescue beacon.