Having read the casesensitivity section of the document you linked to numerous times, I do not see any sentence that implies that case sensitivity of the file system can be changed after it is set.
Ubuntu 20.04 uses OpenZFS 0.8.3 by default, which does not make it easy to change the casesensitivity
value after a pool has been created. It's even stated in the ZFS manage for Ubuntu:
The following three properties cannot be changed after the file system is created, and
therefore, should be set when the file system is created. If the properties are not set
with the zfs create or zpool create commands, these properties are inherited from the
parent dataset. If the parent dataset lacks these properties due to having been created
prior to these features being supported, the new file system will have the default values
for these properties.
casesensitivity=sensitive | insensitive | mixed
Indicates whether the file name matching algorithm used by the file system should be
case-sensitive, case-insensitive, or allow a combination of both styles of matching.
The default value for the casesensitivity property is sensitive. Traditionally, UNIX
and POSIX file systems have case-sensitive file names.
The mixed value for the casesensitivity property indicates that the file system can
support requests for both case-sensitive and case-insensitive matching behavior.
Currently, case-insensitive matching behavior on a file system that supports mixed
behavior is limited to the Solaris CIFS server product. For more information about the
mixed value behavior, see the Solaris ZFS Administration Guide.
Changing of the casesensitivity
property is not permitted for a number of reasons. Assuming a file system was sensitive
or mixed
and suddenly set as insensitive
, there would be the potential for name conflicts:
$ ll
-rw-r--r-- 1 jason jason 220 Feb 25 2020 doc.txt
-rw-r--r-- 1 jason jason 3812 Mar 24 2021 DOC.txt
-rw-r--r-- 1 jason jason 220 Feb 25 2020 Doc.txt
After being set as insensitive
, which file gets returned? By default, an insensitive
index will store everything in lower-case, meaning that you will lose access to DOC.txt
which is larger, more recent, and probably the text file you wanted.
Another reason is overall performance. If a file system needs to handle situations where case sensitivity can be altered at will, it will need to track and manage case conflicts with every file interaction, even if the person using ZFS has no intention on changing the casesensitivity
property. Disallowing the change helps the development team optimise indexes to keep lookups fast.
The last reason (that I'll mention) has to do more with people than technology. We – as a species – excel at creating our own problems and blaming everyone else for the hassles that immediately follow. Rather than have forum after forum filled with people complaining that entire directories of critical data are no longer accessible, it's sometimes better to forbid an action up front. People who really want to change the case sensitivity will learn how to access the hidden .zfs
directory and modify the properties manually and panic when the ZFS Pool crashes but, for everyone else, they'll have to do things differently, which is what I suggest you do, as well.
Rather than change the case sensitivity for the current ZFS Pool, save yourself a world of frustration and create a new ZFS Pool and allocate some storage to it. Ensure it's set as being case insensitive from the beginning, and you'll be good.
For example:
sudo rpool create isamba /dev/sdc -o casesensitivity=insensitive