[PATCH] Fix generic direct IO code for XFS
The following patch to the generic direct IO code fixes a problem we've come across that affects the way XFS interacts with it. Between 2.6.5 and 2.6.6 several changes to direct IO were made, in particular the fallback-to-buffered path was introduced in that timeframe. Those changes split the locking done within direct-io.c into two cases - generic filesystems and blkdev/XFS. There is no locking done for the second case, and we also never set the create parameter to the get_blocks call (via direct_io_worker ->do_direct_IO->get_more_blocks) for that case. This meant that XFS was accidentally no longer being told when a direct IO write was being performed, which in turn meant that XFS would (often - depending on the inode's size and bmap) tell get_more_blocks that it was mapping to a hole. It also means that currently all direct writes into XFS are falling back to buffered writes. Further, skipping the i_alloc_sem locking entirely is not correct for us, we are relying on that aspect of the generic locking. The fallback behaviour from direct to buffered is "silent", so we didn't actually pick up on these problems until just recently, unfortunately. The approach I've taken here is to split the blkdev/XFS case into two, and corrected the new third case behaviour for the functionality XFS provides. The generic behavior used by other filesystems remains unchanged, as does direct IO to the block device, and XFS now becomes fully functional. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Showing
Please register or sign in to comment