On 11/07/2014 01:17 PM, Martin K. Petersen wrote:
I'd suggest trying /dev/sgN instead.
That seems to work. Much appreciated.
And it's now showing an "optimal_io_size" of 0, so I think the issue is
dealt with.
Thanks for all the help, it's been educational. :)
Chris
--
To unsubscribe from
On 14-11-07 12:10 PM, Elliott, Robert (Server Storage) wrote:
commit 87c0103ea3f96615b8a9816b8aee8a7ccdf55d50
Author: Martin K. Petersen
Date: Thu Nov 6 12:31:43 2014 -0500
[SCSI] sd: Sanity check the optimal I/O size
We have come across a couple of devices that report crackpot
> "Chris" == Chris Friesen writes:
Chris> Apparently the "hdparm -I" command is giving bogus data as well.
Chris> I've seen that happen if the drive is on a RAID controller--I
Chris> assume that could cause problems with firmware updates too?
I'd suggest trying /dev/sgN instead.
But yes, so
On 11/07/2014 10:25 AM, Martin K. Petersen wrote:
>> "Chris" == Chris Friesen writes:
>
> Chris,
>
> Chris> Also, I think it's wrong for filesystems and userspace to use it
> Chris> for alignment. In E.4 and E.5 in the "sbc3r25.pdf" doc, it looks
> Chris> like they use the optimal granulari
> "Chris" == Chris Friesen writes:
Chris> Apparently there's a new firmware available, dated Oct 13 but
Chris> with no release notes. We just tried updating the firmware on
Chris> one of the drives in question and it failed from two different
Chris> versions of linux,
Did you use sg_write_b
On 11/07/2014 11:42 AM, Martin K. Petersen wrote:
"Martin" == Martin K Petersen writes:
Martin> I know there was a bug open with Seagate. I assume it has been
Martin> fixed in their latest firmware.
Seagate confirms that this issue was fixed about a year ago. Will
provide more data when I hav
> "Martin" == Martin K Petersen writes:
Martin> I know there was a bug open with Seagate. I assume it has been
Martin> fixed in their latest firmware.
Seagate confirms that this issue was fixed about a year ago. Will
provide more data when I have it.
--
Martin K. Petersen Oracle Linux
> "Rob" == Elliott, Robert (Server Storage) writes:
Rob,
Rob> * the block layer BIO_MAX_PAGES value of 256 limits IOs
Rob> to a maximum of 1 MiB
We do support scatterlist chaining, though.
Rob> * SCSI LLDs report their maximum transfer size in
Rob> /sys/block/sdNN/queue/max_hw_sectors_
> commit 87c0103ea3f96615b8a9816b8aee8a7ccdf55d50
> Author: Martin K. Petersen
> Date: Thu Nov 6 12:31:43 2014 -0500
>
> [SCSI] sd: Sanity check the optimal I/O size
>
> We have come across a couple of devices that report crackpot
> values in the optimal I/O size in the Block Lim
> "Chris" == Chris Friesen writes:
Chris,
Chris> Also, I think it's wrong for filesystems and userspace to use it
Chris> for alignment. In E.4 and E.5 in the "sbc3r25.pdf" doc, it looks
Chris> like they use the optimal granularity field for alignment, not
Chris> the optimal transfer length.
> From: Chris Friesen
> Also, I think it's wrong for filesystems and userspace to use it for
> alignment. In E.4 and E.5 in the "sbc3r25.pdf" doc, it looks like they
> use the optimal granularity field for alignment, not the optimal
> transfer length.
Everything you say suggests that "optima
On 11/06/2014 07:56 PM, Martin K. Petersen wrote:
"Chris" == Chris Friesen writes:
Chris,
Chris> For a RAID card I expect it would be related to chunk size or
Chris> stripe width or something...but even then I would expect to be
Chris> able to cap it at 100MB or so. Or are there storage syst
> "Chris" == Chris Friesen writes:
Chris,
Chris> For a RAID card I expect it would be related to chunk size or
Chris> stripe width or something...but even then I would expect to be
Chris> able to cap it at 100MB or so. Or are there storage systems on
Chris> really fast interfaces that could
On 11/06/2014 12:12 PM, Martin K. Petersen wrote:
"Chris" == Chris Friesen
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
On 2014-11-06 11:12, Martin K. Petersen wrote:
"Chris" == Chris Friesen 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
> "Chris" == Chris Friesen 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
On 11/06/2014 11:34 AM, Martin K. Petersen wrote:
"Chris" == Chris Friesen writes:
Chris> Perhaps the ST900MM0026 should be blacklisted as well?
Sure. I'll widen the net a bit for that Seagate model.
That'd work, but is it the best way to go? I mean, I found one report
of a similar proble
> "Chris" == Chris Friesen writes:
Chris> Perhaps the ST900MM0026 should be blacklisted as well?
Sure. I'll widen the net a bit for that Seagate model.
commit 17f1ee2d16a6878269c4429306f6e678b7e61505
Author: Martin K. Petersen
Date: Thu Nov 6 12:31:43 2014 -0500
SCSI: Blacklist ST90
On 11/06/2014 10:47 AM, Chris Friesen wrote:
Hi,
I'm running a modified 3.4-stable on relatively recent X86 server-class
hardware.
I recently installed a Seagate ST900MM0026 (900GB 2.5in 10K SAS drive)
and it's reporting a value of 4294966784 for optimal_io_size. The other
parameters look norm
Hi,
I'm running a modified 3.4-stable on relatively recent X86 server-class
hardware.
I recently installed a Seagate ST900MM0026 (900GB 2.5in 10K SAS drive)
and it's reporting a value of 4294966784 for optimal_io_size. The other
parameters look normal though:
/sys/block/sda/queue/hw_secto
20 matches
Mail list logo
