Hacker News Reader

Comment by rincebrain | Hacker News Reader

The reason to use zvols is twofold, AFAIR:

- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance

- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage

Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...

But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.

View on HN

I felt the same way about it as you before I started looking for benchmarks as I wrote my previous comment. :)

After all: Why would zvols exist at all if they weren't superior in important ways?

> it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance

It's important to note that additional datasets are essentially free on ZFS; it's no big deal to have lots of them (millions of millions of them is A-OK), and datasets don't have a pre-determined size like zvols do.

Although zvols can also be grown and shrunk, just as files [within datasets] can be.

Both datasets and zvols make the same kind of mess out of zfs list's unfiltered output.

But zvols introduce a new concept, while anyone who uses ZFS is already familiar with datasets that contain files.

I think this part is a wash, and that it comes down to operator preference.

> avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage

Maybe? Again, the benchmarks I found (hours ago now and tabs long-closed; I'll find more if anyone insists) suggested that files were faster than zvols, which suggests reduced overhead. (It's very possible that the tests I found were naively implemented, but then: It's also possible for any of us to do something naive.)

Anyway, it's interesting to think about.

It seems like the right answer is to test with one's own workload and find the best fit, instead of assume that one way is better than the other.

For its part, ZFS should handle a zvol and a file-on-a-dataset with equal stoicism and reliability.

Sure, I'm not suggesting that they're a good idea to use blindly at this point - I think most people are building on filesystem-based setups so most of the polish is going there.

But that was the original logic.

I also would be curious to see benchmarks for them on FBSD and Linux, because FBSD and Linux (the platforms at large) diverged in how they handle "disks", with FBSD opting for only character devices (unbuffered) and Linux only block devices (buffered).

Reply on news.ycombinator.com