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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
