Re: 5.99.42/i386 crash (backtrace + core available)

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Sun Jan 09 2011 at 22:29:19 +0000, Matthias Scheler wrote:
> > Move locking to fs level from vnode level :) *shrugs*
> 
> I still like the AmigaOS model:
> 1.) Each file-system is owned by single AmigaOS process (same as a kernel
>     thread in NetBSD).
> 2.) Any kind of file-system operating is done by sending a message to the
>     file-system process.
> 3.) The file-system processes messages (usually in order) and sends a
>     reply to the originator once it has finished.
> 
> The advantages were:
> 1.) No locking is necessary because the file-system process owns all the
>     data-structures.
> 2.) Layered file-systems are easy. They just accept messages from
>     normal processes, create a new message and send it one layer down.
>     They wait for a reply afterwards and finally send a reply for
>     the original operation.

dateline 2006 a.d.:

Threads and locks are difficult, so let's make the default userspace
file system model based on coprocesses with cooperative scheduling.
That will make things easy.

flash-forward to present day:

Nope.  It turns out that file systems are difficult because file systems
are difficult, not because locking is difficult.  Things are easy as
long as you have exactly one operation in flight.  If you want more than
one to kill backend latency, you start needing all kinds of status bits,
and they are no different from locking.  The only thing you don't need
is atomic intercpu locking, and that might give you a little performance
boost, but that does not make the code fundamentally less complex.

Anecdote: It took me one day to write ssshfs, which executed a request
from start to finish before starting the next one.  I've not counted the
total hours gone into psshfs, but all things considered it's probably
several months of working time.

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa