On Wed, 2008-10-22 at 22:15 +0900, Tejun Heo wrote: > Ric Wheeler wrote: > > I think that we do handle a failure in the case that you outline above > > since the FS will be able to notice the error before it sends a commit > > down (and that commit is wrapped in the barrier flush calls). This is > > the easy case since we still have the context for the IO. > > I'm no FS guy but for that to be true FS should be waiting for all the > outstanding IOs to finish before issuing a barrier and actually > doesn't need barriers at all - it can do the same with flush_cache. > We wait and then barrier. If the barrier returned status that a previously ack'd IO had actually failed, we could do something to make sure the FS was consistent. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
