On Tue, Mar 28, 2006 at 06:55:10PM -0800, Bill Studenmund wrote:
> > another possibility would be to add another flag to indicate that direct
> > I/O requests need not be serialized with each other, only with non-direct
> > requests.  pretty much any application that would actually use direct I/O
> > (eg. databases) would be happy with this, and it would allow us to use
> > the faster mechanism of just taking the vnode lock in a shared mode for
> > all direct requests (though a different shared mode than the normal one,
> > basically we would have two incompatible colors of shared mode).  this
> > particular scheme would unnecessarily serialize direct reads vs buffered
> > reads; this seems unlikely to be a problem in practice, but if desired we
> > could extend it to have four lock colors (the cross product of read vs. write
> > and POSIX vs. concurrent) with the appropriate color-compatibility matrix.
> > actually, this other flag (let's call it O_CONCURRENT for now) wouldn't
> > really need to be tied to O_DIRECT, though allowing concurrent writes for
> > buffered I/O would require a bunch of additional changes beyond those
> > that would be required for concurrent direct I/O.
> 
> To be honest, I think that as long as i/os don't overlap, we're fine. I 
> think it's ok for an O_DIRECT write to be happening at the same time as a 
> non-direct read, assuming they cover different parts of the file.

I mean that this other mechanism would be instead of tracking specific ranges
that have I/O requests outstanding.  it would do exclusion based on requests'
types rather than on requests' offset ranges.  to avoid needing to have
applications specifically know about this new flag, the usual way to invoke
it would probably be a mount option similar to solaris "forcedirectio".

-Chuck