On Thu, Aug 25, 2005 at 11:45:14AM -0700, Zach Brown wrote: > 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.
You might want to look at XFS as a model for this. While it's not clustered it has it's own r/w semaphore to protect block allocations. It's not using the i_alloc_sem at all but some 'clever' behaviour with downgrading the lock after the block allocations are done. > 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. If we're going down that route I'd say provide the callback for filesystems that actually need locking only, but there must be a better way to do that. Note that in any case you're doing lots of work for the buffere path aswell in aio.c that should be nessecary with a bit of refactoring. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
