1

You have: two disks of size X and one of size 2X.

You want: zpool with mirror-like redundancy of size 2X

Concatenation of the two X drives is straightforward with ZFS. But I found no way to mirror the resulting vdev (size 2X) with another 2X disk with ZFS's in-house means.

These (more or less unelegant) solutions came to my mind:

  1. Use OS tools (mdadm for Linux, gstripe for FreeBSD) to connect the two X drives to a single physical device that can be mirrored with the 2X one. But I am uneasy with the additional complexity, platform-dependence, and losing bare-metal benefits of ZFS.
  2. Subdivide the 2X drive into two partitions and create a RAID10 equivalent with four members via zpool create tank mirror /dev/Xone /dev/2Xpart1 mirror /dev/Xtwo /dev/2Xpart2 where the striped partitions are scattered over physically contiguous hardware.
2

ZFS really doesn't support what you want to do. It's possible to wrestle it into doing what you want, but you're fighting the intended use all the way in doing so.

It's worth keeping in mind that ZFS is an enterprise file system and volume manager solution. In an enterprise environment, no matter which way one goes about it, the added complexity of what you describe would dwarf the cost of aquiring drives that are of the same size.

The cleanest solution given what you have probably indeed is to split the larger drive into halves, and then set up a pool with two vdevs each with one of the smaller disks and one half of the larger one. ZFS will then stripe the data between the two vdevs, giving you a two-wide stripe set of two-way mirrors: in standard RAID terms, one RAID 0 of two RAID 1s of two devices each, where one of the devices on each RAID 1 really are portions of a single device. Something like this (where the physical devices are marked with *):

                            _ small1*
                           /
          _ raid0left ----<                    _ largeleft
         /                 \                  /
pool ---<                   >---- large* ----<
         \                 /                  \
          ` raid0right ---<                    ` largeright
                           \
                            ` small2*

See how fragile that looks? For one, lose that large drive for any reason at all, and you lose all redundancy, hugely limiting ZFS' ability to recover from errors.

Doing this will force the larger disk to seek like crazy to satisfy I/O requests, since ZFS will treat it as two separate devices when in reality it's just one, and will very likely turn off many of ZFS' optimizations because ZFS can no longer assume it's in control of the entire larger drive. If it's a rotational drive, that seeking alone will put huge stresses on it.

It will also pretty much lock you into this setup, since at least last I looked, vdevs can only be added to a pool, not removed. You can replace devices within a vdev, but you can't do anything to the vdev itself without destroying and recreating the entire pool. Also remember that every single vdev in a pool needs to be at least DEGRADED for the pool to be functional. Therefore, even in the best of cases, you get no more reliability than a simple mirror configuration, since even in the absence of any other failures, the failure of one physical device degrades both sides of the striping. Better hope in that case that the two small drives hold up to the rigors of a resilver.

If you try to do it anyway, unless the larger disk is a SSD, it seems to me that the seek activity alone will be absolutely devastating to the pool's performance, definitely in terms of IOPS and likely in terms of throughput.

If it were me, I'd just get a second drive of the same size as the larger one, and set up a simple two-way mirror.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.