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

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.
> > >
> > > 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
> >
> > >
>