Chris Mason <chris.mason@xxxxxxxxxx> wrote: > 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. That's because there are no real problems in not honoring barriers - unless your system crashes. > But, that's because they don't actually > rely on the barriers to decide if an async commit is a good idea. As long as they cannot rely on barriers - how should they? [...] > In general, async commits happen with threads and they aren't related to > barriers. If my filesystem said "First update b, then let a point to b", where the H is the thread? > Barriers don't really give us error handling, Each request should give you error handling, but you are right: The whole queue after the barrier must be aborted, too. (Or better: The part depending on the barrier.) > and they are at > the very end of a long chain of technical problems around commits that > don't block concurrent activity. You lost me here, but I guess the end will be a major rewrite. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
