Re: absurdly high "optimal_io_size" on Seagate SAS disk
From: Chris Friesen
Date: Thu Nov 06 2014 - 14:16:01 EST
On 11/06/2014 12:12 PM, Martin K. Petersen wrote:
"Chris" == Chris Friesen <chris.friesen@xxxxxxxxxxxxx>
writes:
Chris> That'd work, but is it the best way to go? I mean, I found
one Chris> report of a similar problem on an SSD (model number
unknown). In Chris> that case it was a near-UINT_MAX value as well.
My concern is still the same. Namely that this particular drive
happens to be returning UINT_MAX but it might as well be a value
that's entirely random. Or even a value that is small and innocuous
looking but completely wrong.
Chris> The problem with the blacklist is that until someone patches
it, Chris> the drive is broken. And then it stays blacklisted even
if the Chris> firmware gets fixed.
Well, you can manually blacklist in /proc/scsi/device_info.
Chris> I'm wondering if it might not be better to just ignore all
values Chris> larger than X (where X is whatever we think is the
largest Chris> conceivable reasonable value).
The problem is that finding that is not easy and it too will be a
moving target.
Do we need to be perfect, or just "good enough"?
For a RAID card I expect it would be related to chunk size or stripe
width or something...but even then I would expect to be able to cap it
at 100MB or so. Or are there storage systems on really fast interfaces
that could legitimately want a hundred meg of data at a time?
On 11/06/2014 12:15 PM, Jens Axboe wrote:
Didn't check, but assuming the value is the upper 24 bits of 32. If
so, might not hurt to check for as 0xfffffe00 as an invalid value.
Yep, in all three wonky cases so far "optimal_io_size" ended up as
4294966784, which is 0xfffffe00. Does something mask out the lower bits?
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/