On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote: > David Chinner wrote: > >The use of barriers in XFS assumes the commit write to be on stable > >storage before it returns. One of the ordering guarantees that we > >need is that the transaction (commit write) is on disk before the > >metadata block containing the change in the transaction is written > >to disk and the current barrier behaviour gives us that. > > Barrier != synchronous write, Of course. FYI, XFS only issues barriers on *async* writes. But barrier semantics - as far as they've been described by everyone but you indicate that the barrier write is guaranteed to be on stable storage when it returns. > so if XFS relies on that block being on > the media when the request is completed, then it is broken. XFS relies on the block being stable before any other write goes to disk. That is the semantic that the barrier I/Os currently have. How that is implemented in the device is irrelevant to me, but if I issue a barrier I/O, I do not expect *any* I/O to be reordered around it. > It should > only care that the ordering of log-data-log is maintained, not exactly > when each specific request completes. Yes, and that is provided to XFS by the fact that barrier I/Os are full barriers.... 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
