On Wed, 2025-09-10 at 10:14 -0400, Chuck Lever wrote: > On 9/10/25 7:10 AM, Jeff Layton wrote: > > On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote: > > > On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > > > On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote: > > > > > > Date: Wed May 21 16:50:46 2008 +1000 > > > > > > > > > > > > dcache: Add case-insensitive support d_ci_add() routine > > > > > > > > > > My memory must be quite faulty then. I remember there being significant > > > > > controversy at the Park City LSF around some patches adding support for > > > > > case insensitivity. But so be it -- I must not have paid terribly close > > > > > attention due to lack of oxygen. > > > > > > > > Well, that is when the ext4 CI code landed, which added the unicode > > > > normalization, and with that another whole bunch of issues. > > > > > > Well, no one likes the Han unification, and the mess the Unicode > > > consortium made from that, > > > But the Chinese are working on a replacement standard for Unicode, so > > > that will be a lot of FUN =:-) > > > > > > > > > That being said no one ever intended any of these to be exported over > > > > > > NFS, and I also question the sanity of anyone wanting to use case > > > > > > insensitive file systems over NFS. > > > > > > > > > > My sense is that case insensitivity for NFS exports is for Windows-based > > > > > clients > > > > > > > > I still question the sanity of anyone using a Windows NFS client in > > > > general, but even more so on a case insensitive file system :) > > > > > > Well, if you want one and the same homedir on both Linux and Windows, > > > then you have the option between the SMB/CIFS and the Windows NFSv4.2 > > > driver (I'm not counting the Windows NFSv3 driver due lack of ACL > > > support). > > > Both, as of September 2025, work fine for us for production usage. > > > > > > > > Does it, for example, make sense for NFSD to query the file system > > > > > on its case sensitivity when it prepares an NFSv3 PATHCONF response? > > > > > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition > > > > > of internationalized file names? > > > > > > > > Linus hates pathconf any anything like it with passion. Altough we > > > > basically got it now with statx by tacking it onto a fast path > > > > interface instead, which he now obviously also hates. But yes, nfsd > > > > not beeing able to query lots of attributes, including actual important > > > > ones is largely due to the lack of proper VFS interfaces. > > > > > > What does Linus recommend as an alternative to pathconf()? > > > > > > Also, AGAIN the question: > > > Due lack of a VFS interface and the urgend use case of needing to > > > export a case-insensitive filesystem via NFSv4.x, could we please get > > > two /etc/exports options, one setting the case-insensitive boolean > > > (true, false, get-default-from-fs) and one for case-preserving (true, > > > false, get-default-from-fs)? > > > > > > So far LInux nfsd does the WRONG thing here, and exports even > > > case-insensitive filesystems as case-sensitive. The Windows NFSv4.1 > > > server does it correctly. > > > > > > Ced > > > > I think you don't want an export option for this. > > > > It sounds like what we really need is a mechanism to determine whether > > the inode the client is doing a GETATTR against lies on a case- > > insensitive mount. > > > > Is there a way to detect that in the kernel? > > Agreed, I would prefer something automatic rather than an explicit > export option. The best approach is to set this behavior on the > underlying file system via its mount options or on-disk settings. > That way, remote and local users see the exact same CS behavior. > > An export option would enable NFSD to lie about case sensitivity. > Maybe that's what is needed? I don't really know. It seems like > a potential interoperability disaster. > There is also the issue that exports can span filesystems. If you have one fs that is case-sensitive mounted on another that is not, and then you export the whole mess, the results sound sketchy. > Moreover, as we determined the last time this thread was active, > ext4 has a per-directory case insensitivity setting. The NFS > protocol's CS attribute is per file system. That's a giant mismatch > in semantics, and I don't know what to do about that. An export > option would basically override all of that -- as a hack -- but > would get us moving forward. Again, perhaps there are some > significant risks to this approach. > The spec is written such that case-sensitivity applies to the whole fs, but in practical terms, would there be any harm in allowing this to be set more granularly? Existing servers would still work fine in that case, and I don't think it would be an issue for the Linux client at least. -- Jeff Layton <jlayton@xxxxxxxxxx>
