Re: Filesystem corruption on RAID1

[Roger Heflin <rogerheflin@gmail.com>]

But even if you figured out which it was, you would have no way to
know what writes were still sitting in the cache, it could be pretty
much any writes from the last few seconds (or longer depending on how
exactly the drive firmware works), and it would add additional
complexity to keep a list of recent writes to validate actually
happened in the case of an unexpected drive reset.  This is probably
more of a avoid this failure condition since this failure condition is
not a normal failure mode and more of a very rare failure mode.

On Thu, Aug 17, 2017 at 3:50 PM, Gionatan Danti <g.danti@assyoma.it> wrote:
> Il 17-08-2017 19:33 Wols Lists ha scritto:
>>
>> Which is fine until the drive, bluntly put, lies to you. Cheaper drives
>> are prone to this, in order to look good in benchmarks. Especially as
>> it's hard to detect until you get screwed over by exactly this sort of
>> thing.
>
>
> It's more complex, actually. The hardware did not "lie" to me, as it
> correcly flushes caches when instructed to do.
> The problem is that a micro-powerloss wiped the cache *before* the drive had
> a chance to flush it, and the operating system did not detect this
> condition.
>
> From what I read on the linux-scsi and linux-ide lists, the host OS can not
> tell between a SATA link glitch and a SATA poweroff/poweron. This sound to
> me as a SATA specification problem, rather than a disk/OS one. However, a
> fix should be possible by examining some specific SMART values, which
> identify the powerloss/poweron condition.
>
> Regards.
>
> --
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.danti@assyoma.it - info@assyoma.it
> GPG public key ID: FF5F32A8