[lkml]   [2000]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: hfs support for blocksize != 512

    > Yes? And it will become simpler if you will put each and every locking
    > scheme into the API?

    No, I didn't say that. I want the API to be less restrictive and make
    the job for the fs a bit easier. IMO the current API is inconsistent
    and/or incomplete and I'm still trying to find out what exactly is
    missing. The VFS is becoming more and more multithreaded, locks are
    (re)moved, but nothing was added for the fs.

    > We have ext2 with indirect blocks, inode bitmaps and block bitmaps, one
    > per cylinder group + counters in each cylinder group. Should VFS know
    > about the internal locking rules? Should it be aware of the fact that
    > inodes foo and bar belong to the same cylinder group and if we remove them
    > we will need to protect the bitmap for a while?

    Ok, let's take ext2 as an example. Of course vfs should only be the
    abstraction layer, but it shouldn't enforce locking rules like you added
    them in ext2. I know the races exists already longer, so you don't have
    to argue about that, but earlier I suggested a simpler solution, the
    problem is that it requires holding an exclusive lock while it would
    sleep. It wouldn't even be in the fast path and would only affect write
    access to the indirect blocks of a single file, it doesn't affect reads
    and it doesn't affect access to other files - that really shouldn't be a
    problem even for a multi threaded environment. But currently this is not
    possible and all I'm trying now is to explore possibilities to make that
    possible, as it would make the life for ext2 and every other fs a lot

    > We have AFFS with totally fscked directory structures.

    Sorry? Why is that? Because it's not UNIX friendly? It was designed for
    a completly different os and is very simple. The problems I know are
    mostly shared with every other fs, that has a more dynamic directory
    structure than ext2.

    > It's insane - protection of purely internal data structures belongs to the
    > module that knows about them.

    I absolutly don't argue against that!

    Anyway, somehow you skipped a lot of my mail, so it seems I have to
    continue to discuss that with myself (hopefully without permanent
    The major problem right now is that writepage() is supposed to be
    asynchronous especially for kswapd, but the fs might have to
    synchronized something _internal_. I think one problem here is that we
    still have a synchronous buffer API, what makes it very hard to
    implement a asynchronous interface. That's why I suggested an I/O
    thread, which can sleep for the caller. Another possibility is to make
    the already existing asynchronus interface in buffer.c available to the
    fs. Anyway, if we want an asynchronous fs interface, we need an
    asynchronous buffer interface, so e.g. writepage() in ext2 can lock the
    indirect block, starts the I/O and gets called back later, another
    writepage() call in the same area has to detect that lock (with a simple
    down_trylock()) and schedules the complete I/O for later. With some help
    from the buffer interface it should be possible pretty easily and ext2
    would actually become much easier again. Something like this would also
    be great for a real AIO support in userspace with great latencies.

    bye, Roman
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.024 / U:8.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site