"Elliott, Robert (Server Storage)" writes:
>> Christoph, did you have some hardware where a higher max_sectors_kb
>> improved performance?
>
> I don't still have performance numbers, but the old default of
> 512 KiB was interfering with building large writes that RAID
> controllers can treat as
hat.com
Adding linux-scsi...
> Subject: Re: [patch] Revert "block: remove artifical max_hw_sectors cap"
>
> Christoph Hellwig writes:
>
> > On Mon, Jul 20, 2015 at 03:17:07PM -0400, Jeff Moyer wrote:
> >> For SAN storage, we've seen initial write and
On Mon, 19 Jan 2015, Alan Stern wrote:
...
If anyone (still?) cares about this bug, commit 3a9794d3 ("sd: Fix max
transfer length for 4k disks") fixes it, with no patches required.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Silicon Valley
--
To unsubscribe f
On Mon, 19 Jan 2015, Alan Stern wrote:
> Are you certain the patch had been applied to the kernel you were testing?
Yeah, I definitely remember the result of "git status" having the patch
ready for commit at the time of build. I'll test it again later tonight.
> Maybe you can add a printk statem
On Mon, 19 Jan 2015, Kenneth R. Crudup wrote:
> Sorry for taking so long to get back to you guys about this (the 3.19-rc
> series has been
> problematic for me in a couple of areas, so I'd let it go for a while):
>
> On Mon, 5 Jan 2015, Alan Stern wrote:
>
> > The patch I posted sets a general
Sorry for taking so long to get back to you guys about this (the 3.19-rc series
has been
problematic for me in a couple of areas, so I'd let it go for a while):
On Mon, 5 Jan 2015, Alan Stern wrote:
> The patch I posted sets a general limit of 32 MB for USB drives that
> don't have a quirk flag
;
> I'm sorry i'm using a 3.10.63 vanilla kernel. So i'm missing a commit?
You said "block: remove artifical max_hw_sectors cap" causes the I/O
errors for you, which should only be in a 3.19-ish kernel.
--
To unsubscribe from this list: send the line "unsubscribe
Am 07.01.2015 um 15:31 schrieb Christoph Hellwig:
> On Tue, Jan 06, 2015 at 02:39:16PM -0800, Nicholas A. Bellinger wrote:
>> The fabric_max_sectors=8192 value is already being exposed by target in
>> block limits EVPD as MAXIMUM TRANSFER LENGTH.
>>
>> I'm guessing that since the host side support
On Tue, Jan 06, 2015 at 02:39:16PM -0800, Nicholas A. Bellinger wrote:
> The fabric_max_sectors=8192 value is already being exposed by target in
> block limits EVPD as MAXIMUM TRANSFER LENGTH.
>
> I'm guessing that since the host side support was not added until June
> 2014 in commit bcdb247c by M
Hi Stefan,
On Tue, Jan 06, 2015 at 12:16:35PM +0100, Stefan Priebe - Profihost AG wrote:
> while testing 595b8ecd47e4dde64f704bf78d8c9b97e070ac67 ([PATCH] block:
> remove artifical max_hw_sectors cap), i came around a problem with some
> crucial m500 ssds direct attached.
>
>
On Tue, 2015-01-06 at 14:39 -0800, Nicholas A. Bellinger wrote:
> On Tue, 2014-12-23 at 09:28 +0100, Christoph Hellwig wrote:
> > On Mon, Dec 22, 2014 at 11:31:53AM +0100, Stefan Priebe - Profihost AG
> > wrote:
> > > Hi,
> > >
> > > since the below patch i've some problems with iscsi.
> > >
> >
On Tue, 2014-12-23 at 09:28 +0100, Christoph Hellwig wrote:
> On Mon, Dec 22, 2014 at 11:31:53AM +0100, Stefan Priebe - Profihost AG wrote:
> > Hi,
> >
> > since the below patch i've some problems with iscsi.
> >
> > The LIO based iscsi Server is full of messages like this:
> > SCSI OP 2ah with t
I will later tonight. For now, I'm using 3.18.x (for another reason), which
doesn't have this commit.
My Linus-latest tree has a "fix" that imposed a hard limit of 32767, which
worked for me then.
On January 5, 2015 12:07:56 PM PST, Alan Stern
wrote:
>On Mon, 5 Jan 2015, Christoph Hellwig wro
On Mon, 5 Jan 2015, Christoph Hellwig wrote:
> On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote:
> > OP here. FWIW, this is what I get when running that command on the SCSI
> > generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the
> > issue:
>
> So it looks
Am 05.01.2015 um 18:17 schrieb Christoph Hellwig:
On Tue, Dec 30, 2014 at 03:15:26PM +0100, Stefan Priebe - Profihost AG wrote:
What is the max_sectors_kb value for them?
# cat /sys/block/sdi/queue/max_sectors_kb
16383
That's odd, it's half of what ATA disks should support. Is this
device a
On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote:
> OP here. FWIW, this is what I get when running that command on the SCSI
> generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the
> issue:
So it looks like this one actually provides sane values, but we don't
On Tue, Dec 30, 2014 at 11:19:07AM -0500, Douglas Gilbert wrote:
> In SCSI, the VPD page 0xb0 (Block limits) has a "Maximum transfer
> length" field (32 bits long). Its units are logical blocks. Useful
> if >0 as 0 means "unreported".
>
> USB to SATA bridges should comply with SAT. However SAT and
On Tue, Dec 30, 2014 at 03:15:26PM +0100, Stefan Priebe - Profihost AG wrote:
> > What is the max_sectors_kb value for them?
> >
> # cat /sys/block/sdi/queue/max_sectors_kb
> 16383
That's odd, it's half of what ATA disks should support. Is this
device attached to the HBA or an expander?
--
To u
On Tue, 2014-12-30 at 11:45 -0500, Alan Stern wrote:
> PS: What's the current situation of my "SCSI: fix regression in
> scsi_send_eh_cmnd()" patch:
>
> http://marc.info/?l=linux-scsi&m=141658469207765&w=2
>
> submitted on November 21? Since it was a bug-fix, I rather expected it
> to g
On Tue, 30 Dec 2014, James Bottomley wrote:
> > All right. How does this patch look?
>
> OK, I suppose. The transfer limits are a little on the low side, but
> for usb-storage (i.e. non-UAS) performance devices, they should be OK.
If you're referring to the 32-KB and 64-KB limits, we know from
On Tue, 30 Dec 2014, Douglas Gilbert wrote:
> IMO about the best SATL is in the MPT SAS-2 and SAS-3 HBAs and
> here is that page for a SAS expander attached SATA disk:
> # sg_vpd -p bl /dev/sg3
OP here. FWIW, this is what I get when running that command on the SCSI
generic device that correspond
On Tue, 2014-12-30 at 11:12 -0500, Alan Stern wrote:
> On Tue, 30 Dec 2014, James Bottomley wrote:
>
> > > _Is_ there any way to communicate the maximum transfer size? I'm not
> > > aware of any SCSI command for it. It isn't part of the USB
> > > mass-storage spec.
> >
> > For the device, it's
On 14-12-30 10:34 AM, Alan Stern wrote:
On Tue, 30 Dec 2014, Christoph Hellwig wrote:
The only limits usb-storage imposes on max_sectors are those needed to
work around bugs in the devices' USB bridges. (Okay, there's also
something for tape drive devices, but it probably doesn't belong in
usb
On Tue, 30 Dec 2014, James Bottomley wrote:
> > _Is_ there any way to communicate the maximum transfer size? I'm not
> > aware of any SCSI command for it. It isn't part of the USB
> > mass-storage spec.
>
> For the device, it's in the Block limits VPD page. However, what the
> device supports
On Tue, 2014-12-30 at 10:34 -0500, Alan Stern wrote:
> On Tue, 30 Dec 2014, Christoph Hellwig wrote:
>
> > > The only limits usb-storage imposes on max_sectors are those needed to
> > > work around bugs in the devices' USB bridges. (Okay, there's also
> > > something for tape drive devices, but i
On Tue, 30 Dec 2014, Christoph Hellwig wrote:
> > The only limits usb-storage imposes on max_sectors are those needed to
> > work around bugs in the devices' USB bridges. (Okay, there's also
> > something for tape drive devices, but it probably doesn't belong in
> > usb-storage -- it should be ha
Am 30.12.2014 um 12:32 schrieb Christoph Hellwig:
> On Sun, Dec 28, 2014 at 01:08:59PM +0100, Stefan Priebe wrote:
>>> Nic, can you fix LIO to expose the proper max xfer size?
>>
>> some more problems while running this patch.
>>
>> My crucial m500 and m550 ssds (i have around 60 in 30 different c
On Sun, Dec 28, 2014 at 01:08:59PM +0100, Stefan Priebe wrote:
>> Nic, can you fix LIO to expose the proper max xfer size?
>
> some more problems while running this patch.
>
> My crucial m500 and m550 ssds (i have around 60 in 30 different cases and
> motherboards but all attached as jbods at LSI
On Sun, Dec 28, 2014 at 10:10:01PM -0500, Alan Stern wrote:
> (Is this a USB device? Presumably you wouldn't have CC'ed the
> linux-usb and usb-storage mailing lists if it wasn't...)
It's a usb attached device. From the inquity information and the
product name it looks like a SATA device attache
On Sat, 27 Dec 2014, Christoph Hellwig wrote:
> On Tue, Dec 23, 2014 at 11:48:40PM -0800, Kenneth R. Crudup wrote:
> > > Looks like we need to quirk it. Can you try to echo different limits
> > > to the /sys/block/sdc/queue/max_hw_sectors_kb file for the device to
> > > find the limit for it?
>
Hi Christoph,
Am 23.12.2014 um 09:28 schrieb Christoph Hellwig:
On Mon, Dec 22, 2014 at 11:31:53AM +0100, Stefan Priebe - Profihost AG wrote:
Hi,
since the below patch i've some problems with iscsi.
The LIO based iscsi Server is full of messages like this:
SCSI OP 2ah with too big sectors 834
On Tue, Dec 23, 2014 at 11:48:40PM -0800, Kenneth R. Crudup wrote:
> > Looks like we need to quirk it. Can you try to echo different limits
> > to the /sys/block/sdc/queue/max_hw_sectors_kb file for the device to
> > find the limit for it?
>
> Looks like it's 32767; making it an even 32K sectors
> To recap for the various lists:
> Vendor: Samsung Model: D3 Station Rev: 0202
> Type: Direct-AccessANSI SCSI revision: 06
> It's the 4TB model:
I forgot to add the USB PID/VID information:
Bus 002 Device 002: ID 04e8:6125 Samsung Electronics Co., Ltd
On Sun, Dec 21, 2014 at 02:44:20PM -0800, Kenneth R. Crudup wrote:
> > I had issues with my Samsung 4GB disk recently in Linus' master tree
> > kernels,
> > and have bisected it to the above commit. When doing running bonnie++ (etc.
> > I get EIOs.
> > Is there a "quirks" available for this opt
On Sun, Dec 21, 2014 at 02:44:20PM -0800, Kenneth R. Crudup wrote:
>
> I had issues with my Samsung 4GB disk recently in Linus' master tree kernels,
> and have bisected it to the above commit. When doing running bonnie++ (etc.
> I get EIOs.
>
> Some info is below, let me know if you need anything
On Mon, Dec 22, 2014 at 11:31:53AM +0100, Stefan Priebe - Profihost AG wrote:
> Hi,
>
> since the below patch i've some problems with iscsi.
>
> The LIO based iscsi Server is full of messages like this:
> SCSI OP 2ah with too big sectors 8344 exceeds fabric_max_sectors: 8192
>
> And the client s
On 10/17/2014 07:12 AM, Christoph Hellwig wrote:
> On Wed, Oct 01, 2014 at 02:12:58PM -0700, Christoph Hellwig wrote:
>> On Wed, Oct 01, 2014 at 06:59:34PM +, Elliott, Robert (Server Storage)
>> wrote:
>>> One supporting example: A low limit interferes with creation of
>>> full stripe writes f
On Wed, Oct 01, 2014 at 02:12:58PM -0700, Christoph Hellwig wrote:
> On Wed, Oct 01, 2014 at 06:59:34PM +, Elliott, Robert (Server Storage)
> wrote:
> > One supporting example: A low limit interferes with creation of
> > full stripe writes for RAID controllers.
>
> Yes, both Linux mdraid and
On Wed, Oct 01, 2014 at 06:59:34PM +, Elliott, Robert (Server Storage)
wrote:
> One supporting example: A low limit interferes with creation of
> full stripe writes for RAID controllers.
Yes, both Linux mdraid and parity raids are often crippled by the
default. The mdadm default of 512kb for
uang
> Subject: Re: [PATCH] block: remove artifical max_hw_sectors cap
>
> As we still haven't made any progress on this let me explain why
> the limit does not make sense: It only applies to _FS request,
> which basically have three use cases:
>
> - metadata I/O. Ge
As we still haven't made any progress on this let me explain why
the limit does not make sense: It only applies to _FS request,
which basically have three use cases:
- metadata I/O. Generally small enough that the limit does not
matter at all.
- buffered reads/writes. We already have a sel
ping?
On Sat, Sep 06, 2014 at 04:08:05PM -0700, Christoph Hellwig wrote:
> Set max_sectors to the value the drivers provides as hardware limit by
> default. Linux had proper I/O throttling for a long time and doesn't
> rely on a artifically small maximum I/O size anymore. By not limiting
> the I
Set max_sectors to the value the drivers provides as hardware limit by
default. Linux had proper I/O throttling for a long time and doesn't
rely on a artifically small maximum I/O size anymore. By not limiting
the I/O size by default we remove an annoying tuning step required for
most Linux insta
43 matches
Mail list logo
