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
> GFS.
*nod*
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
> (DIO_NO_LOCKING)
Looks like a good approach to me - it's cleaner and more extensible
that what we have now....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|