Re: [Joel.Becker@oracle.com: Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs]

[Zach Brown <zach.brown@oracle.com>]

> Currently we don't support buffered aio on any filesystem in
> mainline, so adding crufty code to mainline sounds like a bad idea.
> Zab agreed on that and wants to remove it as much as it gets.

Yeah, we aim to simplify this code.  For the record, it wasn't buffered
aio that was the problem.  There were two naughty moving parts:

First, trying not to block in the dlm when issuing aio ops and tracking
state to restart after dlm ops returned eiocbqueued.  This was just
overly aggressive.  This can behave like block mapping lookups in that
it rarely blocks.  Most aio that people care about (direct io writes to
already allocated regions) will simply be acquiring and releasing
shared-read locks around each op -- trivial local operations.

Second, trying to hold dlm locks around the entirety of aio ops. This
led to the mess of trying to tear down locks in the iocb dtor method.
(which can then race with unmount, aio does __fput on the filp, dropping
the vfsmount ref, before calling dtor.. bleh). We can get around this
by unlocking after performing the block mapping lookups and issueing the
io and introducing a cluster DLM lock which behaves like i_alloc_sem.

So, how about a patch that lets the fs provide a callback to
acquire/release i_alloc_sem at the current sites (dio, notify_change)
that work with it? Most file systems wouldn't provide a callback and
the code would just use the sem as usual, but clustered guys could use
dlm locking.

- z