Mirroring Drives of Different Sizes- Partitioning a Drive

OpenZFS
1

I would like to make a pool with redundancy using a drive which is larger than my other drives, but my understanding is that a mirror or RAIDZ VDEV will only have as much space as the smallest physical device on it. I came to the solution of partitioning my larger drive into smaller partitions and making mirror VDEVs with my other drives using those.
Would this work?
I know that you’re meant to give ZFS the full drive. What would be the drawbacks of multiple VDEVs using the same physical device? Slower accesses, even if they’re mirrored to separate drives? Too many writes to one SSD? Power consumption maybe?

More about my particular situation
I’m new to ZFS and wanted to try it on my personal machine, ideally mirroring the drives I already have. The built-in encryption and error correction are more important to me than surviving drive failures, but I heard that ZFS is meant to be used with mirror/RAIDZ, and it seems I need a mirror anyway if I want to deal with a drive disconnecting from time to time.
My current plan is to use the three drives I have now. This involves mirroring half of my large drive (A) onto my small drive (B), mirroring the other partition onto my other small drive (C), and using a small partition with a bit of space from (C) for ZFSBootMenu.

2

Sorry, but it’s a bad idea. A “mirror” of two partitions isn’t actually either fault tolerant OR a potential read accelerator like an actual two drive mirror, because you still only have a single drive worth of redundancy and performance.

More on performance: a pool’s general performance directly correlates to the performance of its slowest vdev, and a vdev’s general performance relates to the performance of its slowest individual device.

So by creating a pool of three mirror vdevs on three total physical drives, what you’re really doing is hobbling performance to something considerably worse than what your large drive is capable of solo (and worse than any of your small drives can manage solo, also).

You get some redundancy out of it–you can survive a failure of any one disk–but unlike a real pool of mirrors, you’re absolutely guaranteed to lose the pool on the next failure. (To be fair, with only three drives to work with, you don’t have any realistic options for surviving two failures. Others reading this might be considering doing this with more drives, though, so I’m being thorough.)

So you’re getting worse performance–significantly worse–in return for a tiny bit of redundancy. Not a good trade, particularly since I haven’t heard anything about backup.

With, eg, two 10T drives and one 20T drive, here’s what I would do: create two separate pools, one with two single disk vdevs using the 10T drives, and one with a single disk vdev of the 20T drive.

Test performance of each pool (because smaller drives are frequently older and may not be in the best health) and then put the better performing pool into service as production, and replicate frequently and automatically to the other pool for backup.

Ideally, you put the backup pool in another box–can be a literal $50 garbage box eBay buy, if you can’t scrounge something locally–and you replicate to it across the network. This significantly increases the number of catastrophes you can recover from smoothly–ESPECIALLY if you make sure to configure the backup box not to allow ssh logins from the prod box, or at least least that it requires different credentials to log into than the prod box does.

With or without the second box, you get significantly higher performance and dramatically improved disaster recovery capability this was than you would buy carving drives into partitions and trying to “cheat.” :sweat_smile:

3

You said error correction is important and surviving drive failures is not important. Error correction, and surviving failures are very interlinked in my mind, so I want to expand on that. And experience also tells me that you’re likely to start detecting errors when a drive it about to die anyway.

For error correction, are you expecting the kind of error correction you get from network transfer error correcting codes? The kind where we can recover from random bit flips during transmission? ZFS error correction doesn’t exactly work that way, the ZFS checksums can only detect errors, not recover from them. For correcting errors, you really need a mirror or raidz setup.

ZFS is usually more worried about recovering from entire drive sectors failing rather than individual bitflips. Individual bitflips can be detected, but can’t be corrected from the metadata alone.

1 Like