Messages in this thread | | | Subject | Re: Linux v2.4.19-rc5 | From | Steven Cole <> | Date | 01 Aug 2002 08:45:20 -0600 |
| |
On Thu, 2002-08-01 at 03:02, Andrew Morton wrote: > Jens Axboe wrote: > > > > ... > > > Anyway, lets wait for the numbers. > > > > It just 'feels' like the sort of change that might have odd side > > effects. > > It's almost impossible to get READA to do anything. For example, in > current 2.5, if a READA attempt is actually aborted, end_buffer_io_sync > reports a "buffer I/O error". Every time. And nobody has reported this. > > It _is_ possible to hit this in 2.5, because of ext2_preread_inode(). > > Probably, also it's possible to hit it in 2.4 with hundreds of processes > all issuing ext3 directory readahead. But it's pretty remote.
I've never seen this on 2.4.19-rc3 and I've been beating on it pretty hard, running dbench 128 many times. However, 2.5 is another story.
This might not be the best thread to report this, but since the subject came up, I'm getting the following message with recent 2.5.x kernels whenever I run relatively large numbers of dbench clients.
Buffer I/O error on device sd(8,8), logical block XXXXXXX
where logical block repeats 0-6 times. This behavior is repeatable, but only occurs under fairly high load. I ran dbench with increasing numbers of clients, with the following results:
dbench clients Buffer I/O error messages >=48 0 52 1 56 0 64 0 80 11 96 9 112 7 128 4
This particular run was with 2.5.29 with rmap13b and slabLRU patches, but the behavior with 2.5.29-vanilla was similar. Kernel is SMP, no preempt, and /dev/sda8 where dbench was running was mounted ext2. The test box is 2-way p3, SCSI, 1GB memory.
Time to go beat on -rc5 and see if anything falls out.
Steven
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |