ZFS Why is the "normalization" property not changeable after fs creation?

My understanding is that ZFS stores all filenames unmodified, and normalization only applies at comparison time. Therefore, if I can ensure that all my filenames are unique under both the current normalization algo and the one I want to change it to, shouldn't I be allowed to do so? I have a pool that's rather full and I have nowhere to temporarily store the data, so destroying and recreating all filesystems isn't really feasible.
 
I think the problem is that ZFS can't guarantee that every name would be unique under both algorithms (without going through the whole system and comparing everything) so they've taken the simple approach of just making in read-only.

Of course even if it's technically feasible for it to be changed, it doesn't really help your current predicament much as you'd need OpenZFS to be modified to allow you to change it.
 
I think the problem is that ZFS can't guarantee that every name would be unique under both algorithms (without going through the whole system and comparing everything) so they've taken the simple approach of just making in read-only.
Yeah that’s my guess too, but I was hoping someone could confirm this.

If this is indeed the case (i.e. the property is just an integer/enum stored in file system metadata somewhere and is technically trivial to change, I would like to know which byte on my drives I should modify :)
 
The source code is available ... it should take you a few hours to figure out. I suspect that it would take just as long to copy all the data off the disk and back on though. Both have risk.
 
The source code is available ... it should take you a few hours to figure out. I suspect that it would take just as long to copy all the data off the disk and back on though. Both have risk.
I would totally copy everything off and back on if I had the space, but alas there’s just too much data.
 
There are much better ways to safe and/or free up data than this. You also make a lot of assumptions here while in fact the risk of file system corruption is quite high. Just changing the way the filesystem should compare names doesn't exactly automatically free up disk space.

Have you already looked into the more common options such as compression, checking dedup status, looking into snapshot (diskspace) usage (this is the most common culprit of losing free space). But also your optional quotas and reservations, as well as made copies?

(edit)

The reason why this can't be changed is because it would directly affect all the names which have been stored previously. If you start off by comparing names using a normal routine and then somewhere along the way suddenly change this into UTF8 then there's no way to tell how the system would react on names which have been already stored. For all we know it could be possible that changing the comparison method would render some names invalid.

If this happened during file creation then the filesystem could issue an error and deny its usage. But if the name was already on the filesystem then changing the comparison method could be a sure way to corrupt the entire filesystem.
 
There are much better ways to safe and/or free up data than this. You also make a lot of assumptions here while in fact the risk of file system corruption is quite high. Just changing the way the filesystem should compare names doesn't exactly automatically free up disk space.

Have you already looked into the more common options such as compression, checking dedup status, looking into snapshot (diskspace) usage (this is the most common culprit of losing free space). But also your optional quotas and reservations, as well as made copies?
Maybe the wording of my initial question was ambiguous, but I'm not trying to save or free up space. I'm simply trying to change this property because my filesystems were created with the wrong value and I'd like to correct this mistake.

The reason why this can't be changed is because it would directly affect all the names which have been stored previously. If you start off by comparing names using a normal routine and then somewhere along the way suddenly change this into UTF8 then there's no way to tell how the system would react on names which have been already stored. For all we know it could be possible that changing the comparison method would render some names invalid.
My filesystems already have the utf8only property turned on, so all filenames are already guaranteed to be valid. And because normalization only affects filename uniqueness, as long as I can ensure that my filenames are still unique, it seems harmless to modify this property.
 
Back
Top