From: Chris Friesen chris.frie...@windriver.com
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
Chris == Chris Friesen chris.frie...@windriver.com 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
commit 87c0103ea3f96615b8a9816b8aee8a7ccdf55d50
Author: Martin K. Petersen martin.peter...@oracle.com
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
Rob == Elliott, Robert (Server Storage) elli...@hp.com 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
Martin == Martin K Petersen martin.peter...@oracle.com 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
On 11/07/2014 11:42 AM, Martin K. Petersen wrote:
Martin == Martin K Petersen martin.peter...@oracle.com 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
On 11/07/2014 10:25 AM, Martin K. Petersen wrote:
Chris == Chris Friesen chris.frie...@windriver.com 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
Chris == Chris Friesen chris.frie...@windriver.com 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
On 14-11-07 12:10 PM, Elliott, Robert (Server Storage) wrote:
commit 87c0103ea3f96615b8a9816b8aee8a7ccdf55d50
Author: Martin K. Petersen martin.peter...@oracle.com
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
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 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
Chris == Chris Friesen chris.frie...@windriver.com 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 martin.peter...@oracle.com
Date: Thu Nov 6
On 11/06/2014 11:34 AM, Martin K. Petersen wrote:
Chris == Chris Friesen chris.frie...@windriver.com 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
Chris == Chris Friesen chris.frie...@windriver.com 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
On 2014-11-06 11:12, Martin K. Petersen wrote:
Chris == Chris Friesen chris.frie...@windriver.com 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
On 11/06/2014 12:12 PM, Martin K. Petersen wrote:
Chris == Chris Friesen chris.frie...@windriver.com
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
Chris == Chris Friesen chris.frie...@windriver.com 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
On 11/06/2014 07:56 PM, Martin K. Petersen wrote:
Chris == Chris Friesen chris.frie...@windriver.com 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
18 matches
Mail list logo
