[SOLVED] Dataset readonly property doesn't properly inherit

[AlcSi]

Hi,
I think this is a bug report, let me know if it's best on Jira.

TrueNAS CORE version 13.0-U6.1

In the GUI, in Storage > Pools, setting "readonly" for the whole pool doesn't apply the same state to the datasets that were set to readonly : 'inherit'.

What seems to happen is (example) :
- Datasets shows 'inherit (false)' when set to inherit (coming from a fixed, non-inherited state) and the if the pool has readonly : Off
- Datasets with 'inherit (false)' will NOT change to 'inherit (true)' when the pool is set to 'readonly : On' but instead will stay on 'Off', now showing 'false' (without inherit specified), as if they were manually set to Off.
- Checking in 'Edit Options' will show that indeed, the setting seems to have changed from 'inherit (off)' to simply 'Off'.
- Switching the Pool readonly property back to 'Off' will revert both changes :
1. The dataset will now show 'inherit (false)' again in the table
2. The dataset will now show 'inherit (off)' in the 'Edit Options' menu.

tl;dr the inherit state wasn't respected, the dataset only showed 'inherit' when it happened to match the pool's readonly property state, and simply masked 'inherit' when it didn't match, never actually inheriting the property.

Let me know if you prefer me to post this on Jira, or require more informations, clarifications.
I hope it's clear enough, but the behaviour is so strange, it's hard to explain simply.

Thanks

 

[winnielinnie]

Does the command-line reflect the real dataset propertie?

Code:

zfs get -r -t filesystem readonly mypool

 

[AlcSi]

No, but it's slightly different.

If I'm not mistaken, when the dataset has inherit but doesn't match the pool readonly state, zfs get -r -t filesystem readonly mypool returns "temporary" as SOURCE.
If it's forced in the the dateset, it reports "local" as SOURCE.
If it's inherited and matches the pool's readonly state, it reports "inherited from mypool' in SOURCE.

That being said, setting a dataset's ro property to forcedly match the pool's current property state, from a situation where is was inherited but didn't match the pool's current state, reveted it back to inherit.
Which makes absolutely no sense.

I'm growing more confident that this implementation is quite messy right now.

Let me know if I can help further.

 

[winnielinnie]

Okay, now I see what's going on, and there's two things to note:

1. This is the correct (and safe) behavior of the readonly property in ZFS.
2. The TrueNAS GUI does not reflect the "nuance" involved in this property.

Unlike other ZFS properties, when a child's readonly is set to "inherit", it does not immediately apply this property if the parent's property differs. It will apply ("inherit") the readonly property after it is unmounted and remounted again. Hence, this is the reason you see "temporary", because it's still using the older property (until you unmount and remount it.)

To immediately affect a change for readonly, you must directly apply it to the child dataset in question. Otherwise, setting it to "inherit" will only take affect after the next time the dataset is remounted.

* This is unique to the readonly property. Not all ZFS properties behave in the same manner.

** You cannot "test" this using the TrueNAS GUI, since it offers no button to unmount/mount datasets. You can test this in the command-line. Just beware that you could disrupt services and confuse the GUI if you test this on a dataset that is being used for shares, services, and/or jails.

 

[AlcSi]

Oh, I see, so I really stumbled on some kind of exception there.

Thank you for the detailed explanation.