lkml.org 
[lkml]   [1997]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.189 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site