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 > particular? 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 :-). Jeremy. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
