On Fri, Oct 13, 2006 at 01:09:33PM -0500, Russell Cattelan wrote:
> On Fri, 2006-10-13 at 12:48 +1000, David Chinner wrote:
> > On Thu, Oct 12, 2006 at 07:56:38PM -0500, Russell Cattelan wrote:
> > > While trying to fix up GFS2 directio and reading through the code
> > > involving the various lock flags I discovered the DIO_OWN_LOCKING
> > > flag is no longer used.
> > >
> > > XFS recently changed it xfs_vm_direct_IO function to call
> > > blockdev_direct_IO_no_locking for reads and
> > > blockdev_direct_IO_own_locking
> > > for writes. But DIO_OWN_LOCKING is only used in the direct IO read case
> > > so effectively the flag is never checked an therefore can probably be
> > > removed.
> > NACK.
> > This breaks XFS direct writes - the DIO_OWN_LOCKING flag has meaning
> > for direct writes even though a simple grep doesn't give you any
> > hits. get_more_blocks() sets the create flag unconditionally on
> > writes when DIO_OWN_LOCKING is set, and this is needed for XFS to be
> > able to allocate underlying blocks if the direct write is over a
> > hole or past EOF.
> Arrghh you are correct!
> Even more reason to clean this logic up.
No argument here ;)
> look this version over and see what you think.
> comments not in final state but is describing what
> is being changed an why.
> Basically the idea is to have separate flags for locking
> and creation, overloading the flags meant that they were
> specific for XFS needs and therefore did not work for
That was always going to happen as soon as another filesystem
wanted to use it's own locking and had different create semantics...
> Also go to a TRUE state if flag on and a FALSE state if flag off.
> vs the mix of true flag (DIO_LOCKING) vs false flag
Looks like a good approach to me - it's cleaner and more extensible
that what we have now....
SGI Australian Software Group