Re: libata pm

[Tejun Heo <htejun@gmail.com>]

dusty@gmx.li wrote:
>>> Sorry for my late answer, but i had to sort this out first.
>>> After replacing the first PSU with a new Corsair 650W the power no
>>> longer fluctuated more than 0,01 V (and this only when booting up the
>>> drives...) I did a full resync on both raid arrays and got no more
>>> errors or resets, but there were some inconsitencies during sync and the
>>> xfs filesystem on both arrays had to be repaired. Are these problems
>>> caused by the pm resets ?
>>>
>> libata EH won't lose any data as long as the hardware doesn't.  If power
>> fluctuates causing your drive to briefly power down - this does happen and
>> you can hear the drive doing emergency unload when it happens, the data in
>> write buffer can be lost.  On coming back, all that libata can know is
>> that the PHY suffered brief connection loss, so it resets the device and
>> goes on, so the data in the cache is lost now.  It's basically pulling the
>> power plug from the harddrive while write is going on and connecting it
>> back quickly.  You're bound to lose data.
>>
> After I got the new PSU and the raid was in full sync without any error
> for 48h, I thought all problems were gone. Today the sata errors
> reappeared and whenever the load is high enough I get the following:
> 
> ata10.02: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

> ata10.02: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 2 cdb 0x0 data 0
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Those are time outs for FLUSH.  libata told the drive to flush its cache
onto the media and the drive failed to finish that in 30secs.  As FLUSH
itself is a non-data command, this problem usually isn't caused by
transport layer problems.  This is a pretty good clue that the drive is
knee-deep in s**t.  What does 'smartctl -a' tell you about the drive?

-- 
tejun