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@xxxxxxxxxx> 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@xxxxxxxxxx - info@xxxxxxxxxx > GPG public key ID: FF5F32A8 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
