Now this is interesting, and explains your first remark about
critical path. Could you give more details about this planned
spinlock (where it will be locked, and where it will be released), so
that we can avoid overburdening this critical section?
>HOWEVER, if we call back into the filesystem we have to increment
>intermediate dcache counts and release the name lookup spinlock, because
>we can no longer assume that we're in a fast context (what if the
>low-level filesystem needs to allocate memory in order to generate the
>canonicalized name - that's what the first patch I saw did - and we
>certainly cannot hold the spinlock over the allocation!).
What about my second patch? It doesn't use any call to kmalloc. And,
depending on how Andreas' proposal is implemented, it wouldn't need to
call kmalloc directly either (just treat the allocation of the second
dentry the same way as following a symlink).
>So now we changed a very simple operation that didn't need to touch any
>SMP synchronization primitives (the locks are gotten at the very beginning
>and released at the very end of path name lookup for the optimal case), to
>something that needs to release and re-aquire a SMP lock. Trust me, that's
>going to be more than just "noise" performance-wise.
>
>In order to avoid that kind of stuff, I've been trying to rack my brain on
>what could be permissible behaviour.
>
>Note that something I _could_ add to the filesystem is a simple per-dentry
>flag that indicates case-sensitivity. That would not require us to call
>out to the low-level filesystem (with the problems wrt SMP that that
>implies), because we could do it all within the trusted VFS layer (all the
>operations it needs to do are "fast").
So, are you actually worried about the "potential" abuse that might
happen in the filesystem specific code? Just document the
restriction, and all will be fine. After all, we have the same kind
of restrictions in interrupt handlers, and device drivers know how to
handle them.
>So one option I have been toying with is to require that the _only_ kind
>of name aliasing we allow is a case sensitivity issue. That wouldn't be
>hard to do, and to some degree it makes sense (that seems to be the only
>real issue people have had so far). However, then it becomes a question of
>exactly HOW case sensitive do we want to be:
>
> - trivial case: only consider 7-bit A-Z == a-z. This is nice because it
> makes the hash computation simple (case insensitive filesystem would
> simply not use bit #5 in the hash calculations, and we could in fact
> leave it out even for case-sensitive ones because the bit is likely not
> to give us all that much extra information for the hash - our hash
> algorithm already more-or-less assumes that a character really has only
> about 4 bits worth of information in it).
... and you still would have to worry about the memcmp in __dlookup.
> - only slightly harder case: consider 8-bit Latin1. This requires table
> lookups, but at least it's a well-defined and simple small table.
>
> - general case: what do we do for anything else? Is it acceptable to say
> that any filesystem that can handle > 8-bit characters (yes, ext2fs can
> handle them - ask anybody who uses JE on top of Linux) is automatically
> going to be case-sensitive?
>
>The thing that makes me think that having the VFS layer handle
>case-insenstitivity (but nothing else) is a good idea is that it can
>potentially be useful even for things like ext2fs. Imagine having not to
>worry about case in DOSEMU or Wine, but instead doing
>
> int fd = open("/dosc/windows/windows.ini", O_NOCASE | O_RDONLY);
>
>and it would work even if it was a ext2 filesystem?
Interesting...
>What sort of case-insensitivity do various filesystems currently support?
>Are we talking A-Z only, Latin1, or what? I guess we don't really need to
>worry about what could theoretically be the worst case, but what MS-DOS,
>NT, OS/2 etc actually do right now..
>
> Linus
>
Regards,
Alain