Messages in this thread | | | Date | Thu, 7 Aug 1997 16:16:49 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Msdos name alias patch for 2.1.48 |
| |
On Fri, 8 Aug 1997, Alain.Knaff@poboxes.com wrote: > > What is the counterpart of making aliased lookups less efficient? > The other 3 proposals have much more efficient aliased lookups, while > having only a tiny impact (probably far less than 1%) on normal > lookups.
They have had a much more pronounced _conceptual_ burden, of having to introduce stuff to the VFS layer that has absolutely nothing to do with well-behaved filesystems.
Yes, I'm nervous that we will have to do something like that, but I sure as h*ll want to try to avoid it if at all possible.
Note that my interest in speeding up msdos file name lookups is very close to zero, which is why I don't care if msdos filenames cannot use the dcache very efficiently. So I'm not interested in 1% vs 50%, if that 50% is in a filesystem that I don't consider to be very performance-critical in the first place.
No, this is not "fair".
Also note that the dcache name lookup happens with the name lookup spinlock held (you can't see that right now, because the name lookup spinlock doesn't actually exist yet). That allows (will allow) totally SMP-safe pathname lookups without having to get the global kernel lock.
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!).
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 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).
- 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?
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
| |