Ric Wheeler wrote: > The cache flush command for ATA devices will block and wait until all of > the device's write cache has been written back. > > What I assume Tejun was referring to here is that some IO might have > been written out to the device and an error happened when the device > tried to write the cache back (say due to normal drive microcode cache > destaging). The problem with this is that there is no outstanding IO > context between the host and the storage to report the error to (i.e., > the drive has already ack'ed the write). > > If this is what is being described, there is a non-zero chance that this > might happen, but it is extremely infrequent. The checksumming that we > have in btrfs will catch these bad writes when you replay the journal > after a crash (or even when you read data blocks) so I would contend > that this is about as good as we can do.
Please consider the following scenario. 1. FS issues lots of writes which are queued in the block elevator. 2. FS issues barrier. 3. Elevator pushes out all the writes. 4. One of the writes fails for some reason. Media failure or what not. Failure is propagated to upper layer. 5. Whether there was preceding failure or not, block queue processing continues and writes out all the pending requests. 6. Elevator issues FLUSH and it gets executed by the device. 7. Elevator issues barrier write and it gets executed by the device. 8. *POWER LOSS* The thing is that currently there is no defined way for FS to take action after #4 once happens unless it waits for all outstanding writes to complete before issuing the barrier. One way to solve this would be to make the failure status sticky such that any barrier following any number of uncleared errors will fail too, so that the filesystem can think about what it should do with the write failure. 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
