Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: hfs support for blocksize != 512 | Date | Wed, 30 Aug 2000 02:53:47 -0400 (EDT) |
| |
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/
| |