Network filesystem topics [LWN.net]

Network filesystem topics

Posted May 22, 2018 1:02 UTC (Tue) by dgc (subscriber, #6611)
In reply to: Network filesystem topics by jra
Parent article: Network filesystem topics

> Samba has done this for many years already of course.

Yes, it has.

Just to set the record straight, the XFS ascii-ci implementation was done (>10 years ago, IIRC) specifically for avoiding the Samba CI code for performance reasons. On non-trivial directory sizes, the XFS implementation is thousands of times faster than the Samba CI code because it doesn't have to read the entire directory contents on each lookup to search for CI matches.

There are patches for kernel filesystem UTF-8 CI support (which has the same benefits but for UTF8 encoded names), but there's been issues with them that are being worked through at the moment.

-Dave.

to post comments

Network filesystem topics

Posted May 22, 2018 3:39 UTC (Tue) by jra (subscriber, #55261) [Link] (2 responses)

Yeah, I wasn't trying to imply we did it elegantly (you simply *can't* avoid reading the entire directory when you get a cache miss on case when you're in userspace), only that we already did it :-).

Network filesystem topics

Posted May 22, 2018 13:06 UTC (Tue) by epa (subscriber, #39769) [Link] (1 responses)

I suppose you could do some hack like testing for this, THIS and This, before you fall back to reading the whole directory.

Network filesystem topics

Posted May 22, 2018 15:39 UTC (Tue) by jra (subscriber, #55261) [Link]

That sounds like a good idea, but in fact just about all of the clients already do case-preserving correctly, so when we get a miss it's *extremely* likely that the file doesn't exist (and the client is just making sure that's so).

These code paths are already some of the most complex in Samba (getting the *absolutely* correct error message returns here is *essential* to make real applications work here) so I'm loathe to add any more complexity here.

Network filesystem topics

Posted May 23, 2018 13:03 UTC (Wed) by trondmy (subscriber, #28934) [Link] (2 responses)

The problem with networked filesystems is that typically the server owns the case folding algorithm, and the client has no a priori understanding of how it works. When looking at this problem for NFSv4, we found it basically means that we either have to accept a certain amount of dentry aliasing, or we have to impose artificial limitations in order to avoid that behaviour (e.g. by limiting the number of cached dentries to 1 per file per directory).

The easiest solution is to allow for dentry aliasing, but that then leads to interesting corner cases when creating, linking, renaming or unlinking files. For instance, you end up no longer being able to assume that cached dentries are still valid after an unlink or rename operation, and you can no longer perform negative dentry caching when files are created or linked to...

Network filesystem topics

Posted May 24, 2018 12:56 UTC (Thu) by JFlorian (guest, #49650) [Link] (1 responses)

I'd argue that the true "easiest" solution is a case-sensitive filesystem, but obviously that ship sailed with its disaster in tow. What an unfortunate decision.

Network filesystem topics

Posted May 25, 2018 2:12 UTC (Fri) by zlynx (guest, #2285) [Link]

I'm not sure which you're claiming as the disaster.

I would claim that anything other than raw bytes is the disaster. Especially after my experience with OSX and HFS where I once had to completely reformat a laptop to remove a few files after Apple decided to change their Unicode normalization rules.

There was simply no way to get to the old filenames and no way to access the files.

Let the GUI deal with case sensitivity if it must. Let the OS API access a file by an unambiguous stream of bytes terminated by a null.