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

In reply to: Rick Macklem : "Re: FreeBSD NFSv4.1 *CLIENT* - case insensitive filesystems supported? Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported?"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Tue, 20 Jan 2026 00:33:05 UTC
On Sun, Jan 18, 2026 at 5:17 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> 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.
Just to add a little closure to this, when msdosfs is
exported, it is broken for negative name caching
and name caching related to rename.

I will be committing a patch that fixes this soon,
doing what Kostik suggested (what msdosfs does).

rick

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