OpenZFS 2.1.12 Released With Linux 6.3 Compatibility

[phoronix]

Phoronix: OpenZFS 2.1.12 Released With Linux 6.3 Compatibility

OpenZFS 2.1.12 is now available as the latest version of this out-of-tree ZFS file-system kernel driver that works on Linux now with the latest 6.3 kernel stable series all the way back to the v3.10 kernel. Plus OpenZFS 2.1.12 also works on FreeBSD 12.2 and newer...

https://www.phoronix.com/news/OpenZFS-2.1.12

[skeevy420]

Attention all Planets of the Solar Federation

We have assumed control.

What a great version number. As an OpenZFS user I'm waiting on the 2.2/3.0 release. It's chock full of new and interesting features like Blake3, block cloning, and zilsaxattr.

[ehansin]

Attention all Planets of the Solar Federation

We have assumed control.

What a great version number. As an OpenZFS user I'm waiting on the 2.2/3.0 release. It's chock full of new and interesting features like Blake3, block cloning, and zilsaxattr.

OpenZFS devs don't call themselves the priest of the "Temples of Syrinx" for nothing

Or maybe better to say they are the ones fighting the priests, putting up the good fight. It was just the first thing I thought of!

[pWe00Iri3e7Z9lHOX2Qx]

Nice. Looks like the packages landed in the OpenSUSE filesystem repo less than 12 hours later. Time to change my zypper package locks and switch my desktop to 6.3.

[siliciferous]

Nice. Looks like the packages landed in the OpenSUSE filesystem repo less than 12 hours later. Time to change my zypper package locks and switch my desktop to 6.3.

Yeah! Just bumped from 6.1.31 to 6.3.6 on my Gentoo box myself, always a good feeling when our maintainers are on the ball

[skeevy420]

So the other day I was having a bit of a thought experiment about how to use OpenZFS in an immutable root environment and after looking at that table this morning I'm wondering how features like lz4, zstd, blake3, etc work in regards to alternating a dataset between read-only and read-write. Are those features able to alternate between read-only and read-write or does a person have to pick between compressing a /usr dataset with zstd-19 or having a read-only /usr dataset to mimic an immutable root setup.

[ryao]

So the other day I was having a bit of a thought experiment about how to use OpenZFS in an immutable root environment and after looking at that table this morning I'm wondering how features like lz4, zstd, blake3, etc work in regards to alternating a dataset between read-only and read-write. Are those features able to alternate between read-only and read-write or does a person have to pick between compressing a /usr dataset with zstd-19 or having a read-only /usr dataset to mimic an immutable root setup.

Snapshots are always readonly while the underlying datasets are read write, but can be made readonly via the readonly property. As long as compression zstd-19 is set before writing to the dataset, it will be used and things will be compressed on disk (although only if they are compressible), regardless of readonly vs readwrite.

When I read immutable root, I imagine /. For that, you can mount a snapshot as your rootfs. Then you can make changes to the dataset that was the basis for the snapshot, make a new snapshot and either pivot_root or reboot into the new snapshot. Since you are talking about /usr, I am a bit confused, but I suppose for what you want if /usr is to be separate, but switch between readonly and readwrite whenever you want, you could fiddle with the readonly property on a dataset mounted at /usr. That would involve remounting /usr each time.

[ryao]

Attention all Planets of the Solar Federation

We have assumed control.

What a great version number. As an OpenZFS user I'm waiting on the 2.2/3.0 release. It's chock full of new and interesting features like Blake3, block cloning, and zilsaxattr.

Performance should be better than 2.1.y too. There are micro-optimizations all over the codebase, plus improvements to ZIL, ARC, prefetch, scrub and pool import. One of my favorite micro-optimizations is lower fletcher4 checksum overhead on Linux from avoiding unnecessary FPU context saves/restores when processing ABDs:

https://github.com/openzfs/zfs/commit/59493b63c18ea223857066218d6a58b67eb88159

It is not mentioned there since I only learned about this afterward, but this does not apply to FreeBSD because FreeBSD will always save/restore FPU context when context switching the ZIO threads. Interestingly, our ZIO processing on FreeBSD should be slightly faster than on Linux because moving the save/restore to every context switch means we can avoid what would have been many save/restore operations between context switches. If we can find a way to get Linux’s thread scheduler to do the same, we could do another micro-optimization here.

[skeevy420]

Snapshots are always readonly while the underlying datasets are read write, but can be made readonly via the readonly property. As long as compression zstd-19 is set before writing to the dataset, it will be used and things will be compressed on disk (although only if they are compressible), regardless of readonly vs readwrite.

That's exactly what I was thinking was the case, but seeing that yellow no box in the feature matrix made me scratch me head.

When I read immutable root, I imagine /. For that, you can mount a snapshot as your rootfs. Then you can make changes to the dataset that was the basis for the snapshot, make a new snapshot and either pivot_root or reboot into the new snapshot. Since you are talking about /usr, I am a bit confused, but I suppose for what you want if /usr is to be separate, but switch between readonly and readwrite whenever you want, you could fiddle with the readonly property on a dataset mounted at /usr. That would involve remounting /usr each time.

Silverblue sets / and /usr to read-only and moves or symlinks pretty much everything else usually under the root directory that's read-write to /var. The other day I was thinking about how someone could replicate that kind of setup with OpenZFS and when I saw that matrix I started thinking about how that read-only part would work if the above wasn't the case.

[ryao]

That's exactly what I was thinking was the case, but seeing that yellow no box in the feature matrix made me scratch me head.



Silverblue sets / and /usr to read-only and moves or symlinks pretty much everything else usually under the root directory that's read-write to /var. The other day I was thinking about how someone could replicate that kind of setup with OpenZFS and when I saw that matrix I started thinking about how that read-only part would work if the above wasn't the case.

What feature matrix? It sounds like some documentation somewhere has a problem that needs to be corrected, but I am not sure what offhand.