Ric Wheeler wrote: > Waiting for the target to ack an IO is not sufficient, since the target > ack does not (with write cache enabled) mean that it is on persistent > storage.
FS waiting for completion of all the dependent writes isn't too good latency and throughput-wise tho. It would be best if FS can indicate dependencies between write commands and barrier so that barrier doesn't have to empty the whole queue. Hmm... Can someone tell me how much such scheme would help? > The key is to make your transaction commit insure that the commit block > itself is not written out of sequence without flushing the dependent IO > from the transaction. > > If we disable the write cache, then file systems effectively do exactly > the right thing today as you describe :-) For most SATA drives, disabling write back cache seems to take high toll on write throughput. :-( >> IIUC, that should be detectable from FLUSH whether the destaging >> occurred as part of flush or not, no? >> > > I am not sure what happens to a write that fails to get destaged from > cache. It probably depends on the target firmware, but I imagine that > the target cannot hold onto it forever (or all subsequent flushes would > always fail). As long as the error status is sticky, it doesn't have to hold on to the data, it's not gonna be able to write it anyway. The drive has to hold onto the failure information only. Yeah, but fully agreed on that it's most likely dependent on the specific firmware. There isn't any requirement on how to handle write back failure in the ATA spec. It wouldn't be too surprising if there are some drives which happily report the old data after silent write failure followed by flush and power loss at the right timing. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
