Re: Some very basic questions

[Ric Wheeler <rwheeler@redhat.com>]

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.
>   

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.

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 :-)
>   
>> It is more challenging  (and kind of related) if the IO done in (4) has
>> been ack'ed by drive, the drive later destages (not as part of the
>> flush) its write cache and then an error happens. In this case, there is
>> nothing waiting on the initiator side to receive the IO error. We have
>> effectively lost the context for that IO.
>>     
>
> 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).
>   
>> The only way to detect this is on replay (if the journal has checksums
>> enabled or the error will be flagged as a media error).
>>     
>
> If it's not reported on FLUSH, it basically amounts to silent data
> corruption and only checksums can help.
>
> Thanks.
>
>   

Agreed - checksums (or proper handling of media errors) are the only way 
to detect this.

Ric