Ever wondered how the #OpenZFS readonly filesystem property interacts with the ro and rw mount options, and if using mount(8) vs zfs-mount(8) changes anything, and if your choice of platform changes anything?

I certainly hadn't, until I got a bug report that I'd subtly changed a couple of cases in 2.4.2 for Linux. I unbroke it, but not before spending a bunch of time trying to figure out what "unbroke" means. Emphasis on "trying".

Here's the fix, with my endless 🤔 in the collapsed "bonus" section. Good speluncking opportunity available if you'd like to figure it out!

https://github.com/openzfs/zfs/pull/18563

linux/super: properly apply ro/rw mount option to superblock by robn · Pull Request #18563 · openzfs/zfs

[Sponsors: TrueNAS] Motivation and Context f5a9e3a changed how SB_RDONLY was applied to the new mount in a way that was too simplistic - it only sets readonly on the filesystem if the mount was ro,...

GitHub

@robn *ugh* Personally prefer to have "readonly=on" to supersede read-write option of "{zfs-,}mount" commands.

Issue 18557 is really not an issue. "Affected" people ought to not-do-that-if-it-hurts. (Actually, same could be said of my preference (that I ought to not use "{zfs-,}mount" with read-write option on a dataset with "readonly=on" property).)

Anyway, what good is "readonly" property (set to "on") then if it is easily overridden.

#OpenZFS #ZFS

@ax6761 #18557 is a regression in a stable series, so that's unambiguously a bug.

as for what readonly= means, I can make a good argument in each direction. and it looks like others have too, so that's what we've got. its honestly a pretty small deal, but I wouldn't mind some better docs for it all I think