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.024 / U:92.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site