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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:15 EST