Re: hfs support for blocksize != 512

From: Albert D. Cahalan (acahalan@cs.uml.edu)
Date: Wed Aug 30 2000 - 02:53:47 EDT

  • Next message: Alan Cox: "Re: [PATCH] 2.2: Magic patch for older Symbios SCSI"

    Alexander Viro writes:
    > On Wed, 30 Aug 2000, Roman Zippel wrote:

    >> The point is: the thing I like about Linux is its simple interfaces, it's
    >> the basic idea of unix - keep it simple. That is true for most parts - the
    >> basic idea is simple and the real complexity is hidden behind it. But
    >> that's currently not true for vfs interface, a fs maintainer has to fight
    >> right now with fscking complex vfs interface and with a possible fscking
    >
    > Yes? And it will become simpler if you will put each and every locking
    > scheme into the API?
    >
    > Look: we have Hans with his trees-all-over-the-place + journal.

    Mmmm, isn't it just _one_ big tree with different types of nodes?

    > We have AFFS with totally fscked directory structures. Do you propose to
    ...
    > Then check what's left after that locking - e.g. can two
    > processes access the same fs at the same time or not?
    ...
    > Making VFS single-threaded will not fly. If you can show simpler MT one -

    Ext2, XFS, Reiserfs, NWFS, and JFS need a multi-threaded VFS.
    Do we really need a screaming fast multi-threaded AFFS driver?
    Tell me who is doing SPECweb99 benchmarks on AFFS.
    I'd trade away some NTFS performance for a bug reduction.
    Perhaps the trade would be OK for most single-user filesystems.
    Somebody was doing a Commodore 64 filesystem. That just isn't
    going to be mounted on /tmp except as a joke.

    Yeah, I know about the Coda interface and all. People like the
    ease-of-use and reliability offered by in-kernel filesystems.
    Having a complex-to-simple VFS adapter would make this guy happy.
    You don't have to write it or use it.

    > Plan 9 is nice and easy. Without mmap(),
    > without link(), without truncate(), without cross-directory rename() and

    No link() and no cross-directory rename()... how in hell???
    They what, move via copy and delete?
    -
    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 : Wed Aug 30 2000 - 02:55:27 EDT