Re: The INN/mmap bug

From: Alexander Viro (viro@math.psu.edu)
Date: Mon Sep 18 2000 - 12:23:43 EDT

  • Next message: Michael Eisler: "Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee"

    On Mon, 18 Sep 2000, Chris Mason wrote:

    > When reiserfs_get_block is called on the packed data (with create == 1), we
    > unpack it to a full block, so the generic functions can handle
    > dirties/writes from then on. If the data in the page cache isn't up to
    > date, we need to copy the packed data into the page cache so it doesn't get
    > lost in the conversion.

    <boggle> why bother with bh in that case? You can do all this work on the
    ->writepage()/->readpage()/->prepare_write()/->commit_write() level.

    > This isn't for writing directly to the tail, I'm only doing that in
    > writepage, where I always overwrite the tail data with page data.

            Well, duh. Now I can see where the complaints about VFS being
    ext2-friendly at expense of other filesystems come from. Sure thing, if
    you bend your code so that it would use helper functions written for
    different layout model... It will hurt. The question being: what for? These
    functions do not belong to VFS API - they are convenient to implement the
    real thing (address_space_operations) for a class of filesystems, but
    that's it.

            Look how 'no-holes' filesystems are doing that - yup, different
    layout, different helper functions. It would hurt like hell if we would
    try to do e.g. FAT on get_block() level. So that stuff was done on
    ...page() level, originally in fs/fat/inode.c. When it became obvious that
    there are other filesystems that might share the code - well, into
    fs/buffer.c it went. You are in the same situation.

            Moreover, right now I'm testing yet another class (fragment
    support). Currently it's UFS only, but ext2 also might eventually win
    from that. Yup, also work on ..._page() level, doing that in ufs_get_frag()
    would be a horrible PITA.

            I don't see why are you trying to squeeze everything into
    get_block() - it's not even a method anymore...

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Mon Sep 18 2000 - 12:25:46 EDT