Re: [PATCHSET #upstream] libata: improve FLUSH error handling

[Ric Wheeler <ric@emc.com>]

Tejun Heo wrote:
> Ric Wheeler wrote:
>> I think that is a really important knob to have. Not just for RAID
>> systems, but we use the FLUSH_CACHE on systems without barriers mainly
>> when we power down & do the unmounts, etc.
>>
>> If you hit a bad block during power down of a laptop, I can image that
>> have a worst case of (30?) seconds is infinitely better than multiple
>> minutes ;-)
> 
> Fully finishing FLUSH CACHE requires command repetition.  Not fully
> finishing FLUSH CACHE on shutdown means sure data loss.  Given that
> FLUSH CACHE failure is very rare and it's repeatedly retried if and only
> if the device actively indicates failure, I'm not too sure.  Also note
> that if FLUSH CACHE fails, you cannot even trust the FS journal.  Things
> can get silently corrupt.
> 

I do agree with the above, we should try to get the FLUSH done according 
to spec, I meant to argue that we should bound the time spent. If my 
laptop spends more than 30? 60? 120? seconds trying to flush a write 
cache, I will probably be looking for a way to force it to power down ;-)

It is also worth noting that most users of ext3 run without barriers 
enabled (and the drive write cache enabled) which means that we test 
this corruption path on any non-UPS power failure.

ric