I wound up causing a major outage of my services and destroying my home dir

Re:I wound up causing a major outage of my services and dest... by YATA0 on Friday February 18, 2022 @03:47AM (#30383482)

Every generation rediscovers why ZFS exists, and why it was designed the way it is.

[ Parent | on HN ]

Re:I wound up causing a major outage of my services and dest... by ziml77 on Friday February 18, 2022 @10:00AM (#30386558)

One thing I like the idea of, that ZFS doesn't have, is redundancy broken down to a smaller size than the the whole disk so I don't need matched disk sizes and can easily expand a pool. Btrfs does this.

Difficulty aside, I'm wondering if it would be possible for ZFS to implement that as an option without giving up other features.

[ Parent | on HN ]

Re:I wound up causing a major outage of my services and dest... by magicalhippo on Friday February 18, 2022 @01:32PM (#30389336)

You can do it yourself at the cost of (a lot of) performance. Make say 4TB partitions on each drive, and make vdevs across the partitions.

Then you can upgrade by putting the partitions on different drives etc. Of course must then be careful not to put two partitions of the same vdev on the same disk.

The major downside is that ZFS isn't aware that the underlying devices are the same, so IO which looks nicely scheduled as far as ZFS is concerned might cause massive random IO on the underlying disks.

That said, if one could tell ZFS about which zfs-devices share physical hardware, so the IO scheduler would be aware, then that might be a viable strategy. Might be handy in case you have multiple iSCSIs sharing a 10G link as well.

[ Parent | on HN ]

Re:I wound up causing a major outage of my services and dest... by ziml77 on Friday February 18, 2022 @01:52PM (#30389583)

Huh. I hadn't even considered that it would be possible to assign partitions to the vdevs instead of the entirety of the drive. Though I guess it does make sense that you can, otherwise you wouldn't be able to use a drive participating in a vdev as a boot device.

I don't need the feature that badly though. It's just something that's interested me about Unraid (and most consumer NAS devices actually), especially since I'm running 4 2TB drives and 2 3TB drives as a single RAIDZ2 vdev in my home TrueNAS setup.

[ Parent | on HN ]

Re:I wound up causing a major outage of my services and dest... by magicalhippo on Friday February 18, 2022 @01:56PM (#30389637)

> I hadn't even considered that it would be possible to assign partitions to the vdevs instead of the entirety of the drive.

You can even use files[1]! Mostly available for testing though.

It would be nice with a bit more flexibility with regards to the underlying storage, hence this concept. I tested it in a VM and it works fine, just slow when the underlying disks gets trashed. Mostly noticeable on heavy writes and scrubs.

Should work fine on SSDs though, and might possibly even be a boon to very fast NVMe drives (increasing concurrency).

[1]: https://openzfs.github.io/openzfs-docs/man/7/zpoolconcepts.7...

[ Parent | on HN ]