Re: FreeBSD NFSv4.1 *CLIENT* - case insensitive filesystems supported? Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported?

On Sat, Jan 17, 2026 at 2:58 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Fri, Jan 16, 2026 at 4:21 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Fri, Jan 16, 2026 at 4:12 PM Konstantin Belousov <kib@freebsd.org> wrote:
> > >
> > > On Fri, Jan 16, 2026 at 04:05:04PM -0800, Rick Macklem wrote:
> > > > On Fri, Jan 16, 2026 at 3:47 PM Konstantin Belousov <kib@freebsd.org> wrote:
> > > > >
> > > > > On Fri, Jan 16, 2026 at 03:24:38PM -0800, Rick Macklem wrote:
> > > > > > On Fri, Jan 16, 2026 at 6:18 AM Konstantin Belousov <kostikbel@gmail.com> wrote:
> > > > > > >
> > > > > > > On Fri, Jan 16, 2026 at 05:53:56AM -0800, Rick Macklem wrote:
> > > > > > > > On Thu, Jan 15, 2026 at 11:55 PM Cedric Blancher
> > > > > > > > <cedric.blancher@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, 12 Jan 2026 at 23:04, Rick Macklem <rick.macklem@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Jan 12, 2026 at 1:56 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Jan 12, 2026 at 11:52 AM Cedric Blancher
> > > > > > > > > > > <cedric.blancher@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Good evening!
> > > > > > > > > > > >
> > > > > > > > > > > > Does the FreeBSD >= 14.3 NFSv4.1 client and server support case
> > > > > > > > > > > > insensitive filesystems, e.g. exported ZFS or FAT?
> > > > > > > > > > > Greater than, as in 15.0.
> > > > > > > > > > Oops, that's 15.1->
> > > > > > > > > > (I looked and it is in stable/15, but not releng/15.0.)
> > > > > > > > > > (I work with main and the stable branches and don't keep track of when the
> > > > > > > > > > releases branch off.)
> > > > > > > > >
> > > > > > > > > What about the FreeBSD 15.x NFSv4.2 client - does it support
> > > > > > > > > case-insensitive filesystems?
> > > > > > > > I suppose. It doesn't care. If an application cares (I don't know of
> > > > > > > > one, offhand), it can check via pathconf(2) to see if the fs is
> > > > > > > > case-insensitive (the _PC_CASE_INSENSITIVE pathconf name
> > > > > > > > was added recently and will be in 15.1).
> > > > > > >
> > > > > > > If the client uses namecache, then I suppose it cares, esp. about caching
> > > > > > > the negative lookups.  Also for renames and deletes, the whole set of
> > > > > > > cached entries for the directory must be expunged.
> > > > > > Good point. I did have looking at this on my "to do" list, but forgot
> > > > > > about it. So, I suppose that the current answer is "the NFS client
> > > > > > does not handle case-insensitive file names correctly" until handling
> > > > > > of negative name caching is fixed.
> > > > > >
> > > > > > Initially, I might just disable name caching for case-insensitive file
> > > > > > systems.
> > > > > >
> > > > > > It sounds like the name caching code should have an option for
> > > > > > case-insensitive name comparison?
> > > > > > (For plain ASCII, that should be straightforward, but for non-ASCII
> > > > > > character sets?? I am not conversant with how case insensitivity is
> > > > > > handled for non-ASCII character sets. I know that ZFS has some
> > > > > > "form" options, but that's all I know?)
> > > > >
> > > > > Msdosfs is case-insensitive by MS requirements. It also has some
> > > > > complications due to long names translations to the 8.3 FAT16 format.
> > > > >
> > > > > Due to this, msdosfs does not cache -ve entries at all.  This, together
> > > > > with cache purge for the directory on rename or remove, should be enough.
> > > > > Of course, this assumes that lookup would match a dirent entry right
> > > > > WRT the case.
> Thinking about it a little more, I think I will try
> the msdosfs way. I am working on setting up some
> testing to first try and break the broken client.
Hmm. Turns out it doesn't seem to be broken.
Here's what happens...

For negative name caching, I wrote a little test program that..
(it expects "aaa"/"AAA" to not exist)
1 - attempts to open "aaa", which doesn't exist
2 - create a file called "AAA"
3 - attempts to open "aaa" again
#3 should succeed for a case-insensitive fs

Over an NFS mount, #3 does succeed.
#1 creates a negative cache entry for "aaa"
#3 finds the negative cache entry, but invalidates
     it because the mtime of the directory has changed,
     due to #2.
(This directory mtime change check is to handle
other clients from creating an entry, but it handles
this case as well.)

For rename, I created a little program that does..
(it expects "AAA" to exist)
1 - opens "aaa"
2 - opens "AAA"
3 - renames "AAA" to "BBB"
4 - attempts to open "aaa"
5 - attempts to open "AAA"

#4 and #5 should fail and, for the NFS mount of
the case insensitive fs they do.
What happens..
#1 and #2 create positive cache entries for
  "aaa" and "AAA".
#3 gets rid of the cache entry for "AAA".
#4 finds the positive entry for "aaa", but
invalidates it, since the ctime of the directory
was changed by #3, so #4 fails
#5 fails because the positive entry was
purged by #3.

Now, I suppose that a server file system that
doesn't maintain mtime/ctime well (I don't think
msdosfs/fat maintains a ctime?) could be broken,
so adding code to disable negative name caching
and cache_purge(fvp) in rename is probably
a good idea.
--> But at least for a ZFS exported case-insensitive
      fs, it seems to work ok now.

rick


>
> Thanks for your comments, rick
>
> > > > >
> > > > > I do not know exactly how the non-ASCII codepoints are handled by our
> > > > > msdosfs, but I am sure that we do not have unicode tables for convertion
> > > > > between cases.  In other words, we most likely do not handle them well.
> > > > >
> > > > > Does nfs client know if the server is case-insensitive?
> > > > Yes, for main (and 15.1 when it gets released).
> > > > So, I have a little while to fix it.
> > > > msdosfs and ZFS are patched to return 1 for pathconf()
> > > > for _PC_CASE_INSENSITIVE and the NFS client now
> > > > gets this info. (It only gets a boolean indicating if the
> > > > server file system is case-insensitive. It does not get any
> > > > other info like what ZFS has, below.)
> > > >
> > > > ZFS appears to completely disable name caching when the
> > > > file system has normalization set to other than none (if I read
> > > > the code correctly?).
> > > > >From "man zfsprops"..
> > > > normalization=none|formC|formD|formKC|formKD
> > > > (I have no idea what these mean, but I am guessing that there
> > > > is code in ZFS for these. Of course, it will CDDL'd, so it cannot
> > > > be included in the base system.)
> > > >
> > > > >  Then it could
> > > > > act similarly to our msdosfs.  But again, I do not think that msdosfs
> > > > > informs nfs server that it is case-insensitive.
> > > > Yes, I think this would be sufficient for now.
> > > > (I was thinking of putting a nfs_XXX() front end for the cache_XXX()
> > > > calls. It could map names to "all lower case" for the case insensitive
> > > > case, but that only works for plain ASCII.
> > > > If there was a mount option that completely disables name caching
> > > > instead of mapping to "all lower case", that would cover the non-ASCII
> > > > case, I think?)
> > > Disabling caching at all would work, but would probably also be quite
> > > inefficient.
> > Yes. I'll admit I have never heard anyone report problems with this.
> > I suspect that means that NFS servers that are configured with
> > case-insensitive file systems are not commonly mounted by the
> > FreeBSD client (this name caching bug has always been there).
> >
> > Cedric might know how the NFS server in Windows Server handles
> > this?
> > --> Does it just do case-insensitive file name comparisons or is it
> >      somehow configurable or ???
> >
> > I don't think inefficient will be a problem for msdosfs and I doubt
> > many configure ZFS file systems as case-insensitive on FreeBSD?
> > (I can see the use case of a Windows NFSv4.1/4.2 client mounting
> > FreeBSD ZFS exports, but I suspect those file systems will not often
> > be mounted by FreeBSD clients?)
> >
> > rick
> >
> > >
> > > I implemented nonc option for tmpfs, you might grep for rm_nonc in fs/tmpfs
> > > to see how the plumbing works.
> > >
> > >
> > > > --> Does this sound like a reasonable plan? rick
> > > >
> > > > >
> > >