On 05/27/2009 02:07 AM, Tejun Heo wrote:
> The above is the offending failure and all three failfast bits are
> set.  This corresponds to the following ATA exception.
>
>   ata1.00: cmd 60/08:18:6f:88:6f/01:00:0e:00:00/40 tag 3 ncq 135168 in
> 	  res 50/00:40:d1:71:b8/00:00:09:00:00/40 Emask 0x10 (ATA bus error)
>
> It's 33 page long read command.  Looking at the code the only way all
> three fastfail bits can be set seems to be if the request is readahead
> - the first part of block/blk-core.c::init_request_from_bio().  Now,
> the failure of a readahead request isn't supposed to cause any
> problem.  If it fails, well, it fails and things should go on as if
> nothing happened.
>
> Can you please try the attached patch?  It takes suspend/resume cycle
> out of the equation and simply induces artificial failure to readahead
> requests.  It's currently set to fail every 40th readahead.  Feel free
> to adjust the frequency as you see fit.  catting files into /dev/null
> would trigger readahead to kick in.  Can you reproduce filesystem
> failure with this alone?
>    

No corruption, I tried cat on an entire directory of mp3s, then also 
started X, but there the messages debug output got fairly drastic so I 
didn't care to continue for an entire day.

It did trigger the "XXX ...failing readahead" message nearly 300 times, 
and I also did a s2disk and resume cycle in there - so I hope this is 
enough for us to conclude that it is not the cause.

Regards,
Niel