On Wed, 2009-03-25 at 18:39 -0400, Mikulas Patocka wrote: > > The error handling is complex, no doubt > > about that. But the trial barrier test is pretty trivial and even could > > be easily abstracted out. If a later barrier write fails, then that's > > really no different than if a normal write fails. Error handling is not > > easy in that case. > > I had a discussion with Andi about it some times ago. The conclusion was > that all the current filesystems handle barriers failing in the middle of > the operation without functionality loss, but it makes barriers useless > for any performance-sensitive tasks (commits that wouldn't block > concurrent activity). Non-blocking commits could only be implemented if > barriers don't fail. > If a barrier fails at runtime, the filesystems do fall back to not doing barriers without real problems. But, that's because they don't actually rely on the barriers to decide if an async commit is a good idea. One exception is reiserfs, which does one wait_on_buffer at a later time if barriers are on. But, this isn't an async commit, this is just moving an unplug. In general, async commits happen with threads and they aren't related to barriers. Barriers don't really give us error handling, and they are at the very end of a long chain of technical problems around commits that don't block concurrent activity. -chris -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
