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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux