Re: Some very basic questions

[Ric Wheeler <rwheeler@redhat.com>]

Tejun Heo wrote:
> 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?
>
>   
I think that this is where SCSI ordered tags come in (or similar 
schemes). The idea would be to have tag all IO. You bump the tag, for 
example after you send down the journal data blocks to a new tag which 
is used for the commit block data sequence.

The ordering would require that lower ranked tags must all be destaged 
to persistent storage before a subsequent tag is written out.

The T13 had a microsoft proposal that is in this area:

http://www.t13.org/Documents/UploadedDocuments/docs2007/e07174r0-Write_Barrier_Command_Proposal.doc


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

I have seen a 50% reduction in my testing on S-ATA :-(

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

ric