Re: [PATCH 4 of 8] Add flags to control direct IO helpers

[Chris Mason <chris.mason@oracle.com>]

On Thu, Feb 08, 2007 at 09:33:05AM +0530, Suparna Bhattacharya wrote:
> On Wed, Feb 07, 2007 at 01:05:44PM -0500, Chris Mason wrote:
> > On Wed, Feb 07, 2007 at 10:38:45PM +0530, Suparna Bhattacharya wrote:
> > > > + * The flags parameter is a bitmask of:
> > > > + *
> > > > + * DIO_PLACEHOLDERS (use placeholder pages for locking)
> > > > + * DIO_CREATE (pass create=1 to get_block for filling holes or extending)
> > > 
> > > A little more explanation about why these options are needed, and examples
> > > of when one would specify each of these options would be good.
> > 
> > I'll extend the comments in the patch, but for discussion here:
> > 
> > DIO_PLACEHOLDERS:  placeholders are inserted into the page cache to
> > synchronize the DIO with buffered writes.  From a locking point of view,
> > this is similar to inserting and locking pages in the address space
> > corresponding to the DIO.
> > 
> > placeholders guard against concurrent allocations and truncates during the DIO.
> > You don't need placeholders if truncates and allocations are are
> > impossible (for example, on a block device).
> 
> Likewise placeholders may not be needed if the underlying filesystem
> already takes care of locking to synchronizes DIO vs buffered.

True, although I don't think any FS covers 100% of the cases right now.

> 
> > 
> > DIO_CREATE: placeholders make it possible for filesystems to safely fill
> > holes and extend the file via get_block during the DIO.  If DIO_CREATE
> > is turned on, get_block will be called with create=1, allowing the FS to
> > allocate blocks during the DIO.
> 
> When would one NOT specify DIO_CREATE, and what are the implications ?
> The purpose of having an option of NOT allowing the FS to allocate blocks
> during DIO is one is not very intuitive from the standpoint of the caller.
> (the block device case could be an example, but then create=1 could not do
> any harm or add extra overhead, so why bother ?)

DIO has fallen back to buffered IO for so long that I wanted filesystems
to explicitly choose the create=1 for now.  A good example is my patch
for ext3, where the ext3 get_block routine needed to be changed to start
a transaction instead of finding the current trans in
current->journal_info.  The reiserfs DIO get_block needed to be told not
to expect i_mutex to be held, etc etc.

> 
> Is there still a valid case where we fallback to buffered IO to fill holes
> - to me that seems to be the only situation where create=0 must be enforced.

Right, when create=0 we fall back, otherwise we don't.

> 
> > 
> > DIO_DROP_I_MUTEX: If the write is inside of i_size, i_mutex is dropped
> > during the DIO and taken again before returning.
> 
> Again an example of when one would not specify this (block device and
> XFS ?) would be useful.

If the FS can't fill a hole or extend the file without i_mutex, or if
the caller has already dropped I_MUTEX themselves.  I think this is
only XFS right now, the long term goal is to make placeholders fast
enough for XFS to use.

-chris