On Wed, 30 Aug 2000, Albert D. Cahalan wrote:
> Ext2, XFS, Reiserfs, NWFS, and JFS need a multi-threaded VFS.
> Do we really need a screaming fast multi-threaded AFFS driver?
Erm... Roman seems to complain about VFS/VM not locking hard enough to
make protection of private fs data structures unnecessary.
> 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.
<blinks> What? You are trying to say that debugging the kernel code is
easier than doing that in userland? Could you pass me this reefer? Seems
to be some fairly strong stuff in there... There are reasons to write
kernel fs, but reliability is _not_ one of them; debugging will be harder
with all usual consequences.
> Having a complex-to-simple VFS adapter would make this guy happy.
> You don't have to write it or use it.
Albert, care to look at the API someday? Areas of major suckage:
->revalidate()
->truncate()
->readdir()
It's too fscking close to 2.4 for further cleanups in these places. The
rest is in funny state - simple, but badly documented.
It's much simpler than it used to be and I really wonder what
simplification would you propose. Full lock on all operations? But one
can do it right now - it's not worth a special translator... The only
thing to watch for: ->writepage() (i.e. pageout) can happen anywhere below
the ->i_size and you can't use blocking exclusion against that. Rationale:
trivial deadlocks upon the memory pressure.
If fs has no holes (AFFS, HFS, etc. qualify) - no block allocation
on pageout, so your life is relatively simple. And the rest of
file-modifying stuff is
a) process-synchronous
b) called with ->i_sem held.
For files-with-holes you have to step carefully. Fixed that in ext2, but
expanding to the rest will take a while. Fortunately they are relatively
sane in other respects and happen to be very similar...
[VFS comparison]
> > 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?
So do we, if the target is on a different filesystem... So does AFS, for
that matter (no cross-directory rename). I can understand them very well -
full-blown rename() is _hell_ to get right. BT, DT in VFS, got the nausea.
Grep for "Hastur" in fs/namei.c and read the comments. POSIX, <expletives>
Fortunately, these days fs side of ->rename() is mostly painless (compared
to what had been there; there _is_ some crap, but that's what you get from
the fscked semantics of the operation).
'sides, you had been one of the most vocal link(2)-haters, hadn't you?
-
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 : Thu Aug 31 2000 - 21:00:25 EST