Description
Describe the feature would like to see added to OpenZFS
Unless I've badly misunderstood, it would appear that ZFS currently has a hardcoded limit on file name length of 256 bytes (255 + NUL?), anything longer is rejected.
While this isn't unusual for a file system, it does mean that there are file systems that handle names that ZFS cannot, which makes transitioning to ZFS more complicated.
For example, ExFAT on any platform, as well as HFS+ on macOS both support file names up to 255 UTF-16 characters, which means that file-names transferred to ZFS could be limited to as little as 127 or fewer characters depending upon the number of multi-byte characters.
I would like to see the ability to increase the maximum file name length, either as standard (if this has no legacy issues), or through the use of a property to set an increased limit.
How will this feature improve OpenZFS?
It will remove one of the few limits of ZFS that is relatively low compared to other file systems, especially since it already allows all unicode (except NUL) and has unlimited (at a filesystem level) path names. Having the filename comparatively limited seems overly restrictive for an otherwise very permissive filesystem.
Crucially this will improve compatibility when migrating from other filesystems to ZFS, as it will eliminate the need to either truncate such long file names or use ZVOLs instead to retain them (i.e.- continuing to use the other file system anyway).
Additional context
I'm unclear on what the actual technical limitation is; I've seen some threads here and there discussing possible reasons for why the limit was set where it is in the first place (compatibility with other filesystems or kernel limitations at the time) but as far as I can tell there is no real reason for it to be limited as it is today, though I recognise it could be hardcoded in more places than just file naming (I've tried to look but didn't find any).
This would make the main questions; how much to raise the limit by (or whether to have one at all) and whether it should be applied retroactively as a default?
If there are no technical limitations, my preferred solution would be to move the filename limit into a ZFS property; for the sake of consistency the default for all new and existing datasets could still be the current limit of 255/256 bytes. However it should be configurable to both smaller and larger values, probably up to some unsigned integer limit large enough to be effectively unlimited (with the caveat that very large names could have an impact on performance).
Ideally it should be possible to change this limit at any time (not just at dataset creation), but this will likely depend upon where the current limit is checked. If it's only checked when a file is set then this will make implementation a lot easier, but if there are any structures that rely on the current size, for example to store directory contents, then this may not be possible. Hopefully someone more familiar with the code than myself can comment.
Setting a size larger than the default may require a feature flag, but this will depend on whether other ZFS versions will actually fail when they encounter a longer than normal name. It's possible older versions of ZFS may just require the filename to be shortened when renaming the file, which arguably isn't significant enough to justify a feature flag. A feature flag may however be warranted if the difference in filename limits would cause moving a file to fail, as this would breach the general rule that once a file has been named it should be possible to move it freely (to any valid location), though this may still be minor enough to not warrant it (it's just a caveat of setting the larger limit in the first place, i.e- check your names before downgrading).
Apologies if there have been any similar issues, the only one I found was #2344 which was referring specifically to the fact that the filename length limit was (at the time) undocumented.