On Sun, 7 Jul 2002, Conrad Minshall wrote:

> >Hmmm, I didn't explain what I wanted well enough :-)
> >
> >I want to preserve case sensitive behaviour for NFS and UNIX clients,
> >while reducing the current high cost to CIFS users of providing
> >case-insensitive behaviour.
> 
> Nice goal.  If you had a case-insensitive local filesystem, like a Mac or a
> PC, then that particular performance issue wouldn't exist.  (Don't get me
> wrong, I dislike case-insensitivity for many reasons, for instance it
> breaks kernel "negative-name-cacheing".)

Yes, it does doesn't it.
 
> My point was only that being non-case-preserving will break other users of
> the local filesystem.  A trivial & contrived example:
>   client A smb-mounts sharepoint M from server S
>   client B nfs-mounts M from server S
>   client A creates a file in M, naming it "Foo"
>   (server A creates a monocase file, "foo" for instance)
>   client A finished initializing Foo
>   client A appends "Foo" to file "tobeprocessed"
>   client B notices the addition to "tobeprocessed"
>   client B fails to find "Foo".  Oops.
> In general, the point is that filenames are often imbedded into data, and
> that using any non-case-preserving network file system is likely to break
> case-sensitive filesystem accesses to the underlying shared metadata.  No
> doubt I'm stating the obvious.  Sorry if all this was clear from my first
> response.

Yes, I discarded that idea a while ago, and have begun looking at what it 
would take for the file system to support both views.

I looked at using a case-insensitive hash function for the name cache, and 
actually implemented it until I realized that it did not help.

We had an interesting discussion about this on #samba-technical a few days 
ago, and there are some hard problems. However, NetApp do it :-)

One of the ideas we had was insert the name the user asked for, in the 
case that there is not an exact match, and hard-link it to the file you 
decided on when you opened the file. This prevents problems like:

  file foo.txt exists
  CIFS client asks to open FOO.TXT
  CIFS client matches foo.txt, opens it, and client is happy
  CIFS client closes file
  UNIX user creates file FOO.TXT with random junk
  CIFS user askes to open FOO.TXT again, and now gets a different file.

However, this adds extra names for the same file that will be visible to 
clients, and so on.

>From the description that NetApp provides, it seems like they keep, at 
least logically, two directories, one for UNIX clients and one for CIFS 
clients. However, the cost there is that names must be inserted in both 
directories. The alternative might be for all dirents to contain two names 
(or perhaps three, because you have to support Unicode names for CIFS as 
well as 8,3 names for CIFS, and, maybe, ascii names for UNIX clients). But 
then searching becomes more difficult.

So, there are problems ... but some people would like to solve them.

Regards
-----
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED]


Reply via email to