On Fri, Sep 26, 2014 at 09:37:11PM +0200, Olaf Weber wrote:
> My argument against "mount time case-insensitivity" and for "mkfs
> time case-insensitivity" is related to switching from the
> case-sensitive domain to the case-insensitive one.
> For case-sensitive, from "README" to "readme" there are 64 different
> possible filenames. Let's say you create 63 out of these 64. Now
> remount the filesystem case-insensitive, and try to open by the 64th
> version of "readme". It is not an exact match for any of the 63
> candidate files, and a case-insensitive match to all 63 candidate
> files. Which of these 63 files should be opened, and why that one in
I'm ok with "mkfs time case-insensitivity" - really !
Most of my OEMs would set that and claim victory (few
of them care much about NFS semantics :-).
> >Having CI matching can speed up Samba operations by a
> >factor of 10 on large directories (warning, number made
> >up, depending on the number of entries per dir :-).
> I really want that to be true, but the proof of the pudding...
No it really *is* true. The reason I can't give
exact numbers is it depends on the number of entries.
Remember, for every cache *miss*, we have to scan
the entire directory.
So a user asks for README, and we attempt that
and it fails. So now we have to enumerate the
entire directory to see if READMe (or any other
case varient) exists.
Now do that in a directory with 10, 100, 1000,
.... 10000000 existing files (don't laugh, I've
seen an application for Music files that did
*exactly* that). On a case insensitive filesystem
you just request README and you're done.
Certain vendors who shall remain nameless :-)
created test cases of just this example to
show how much storage on Linux sucks. Not
a happy camper about that - and telling them
to use ZFS on FreeBSD or Solaris just doesn't
feel right :-).