Re: block: remove artifical max_hw_sectors cap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
> > > 
> > > 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 says:
> > > Buffer I/O error on device sdd, logical block 38861907
> > > lost page write due to I/O error on sdd
> > > 
> > > May be some code fixes for iscsi client is missing?
> > 
> > No, the problem seems that the the target is enforcing a size limit
> > without communicating it through the block limits EVPD page.
> > 
> > Nic, can you fix LIO to expose the proper max xfer size?
> 
> 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 MKP, Stefan is likely using an earlier
> initiator that is not honoring this value.
> 
> However, this same issue has been reported elsewhere [1] with an MSFT FC
> host sending I/Os of 8 MB that also doesn't appear to honor block limits
> MAXIMUM TRANSFER LENGTH either.
> 
> So that said, I think it's about time to go ahead and drop the arbitrary
> limitation of fabric_max_sectors, and simply enforce a sane limit (eg:
> not UINT_MAX) for hw_max_sectors.
> 
> The only limitations for backends that I'm aware of is the FILEIO
> FD_MAX_BYTES limit for the number of iovecs per vfs_[writev,readv] call,
> and for IBLOCK what queue_max_hw_sectors() reports for raw block
> make_request() based drivers that aren't able to 
> 

... split large I/O requests into smaller ones.

> I'll put together a patch soon to drop the fabric_max_sectors stuff, and
> use the existing hw_max_sectors to enforce any backend specific I/O size
> limitations.
> 
> --nab
> 
> [1] http://www.spinics.net/lists/target-devel/msg08024.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe target-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux