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. > > 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 ?) 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. > > 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. Regards Suparna > > -chris -- Suparna Bhattacharya (suparna@xxxxxxxxxx) Linux Technology Center IBM Software Lab, India - 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
