Re: hfs support for blocksize != 512

From: Albert D. Cahalan (
Date: Wed Aug 30 2000 - 01:53:47 EST

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
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:25 EST