From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin K. Petersen" Subject: Re: Fwd: [PATCH 1/1] sd: do not let LBPME bit stop the VPDs speak Date: Thu, 10 Mar 2016 21:08:02 -0500 Message-ID: References: <56df97e0.d08d420a.58e8f.3162@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from userp1040.oracle.com ([156.151.31.81]:23943 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933386AbcCKCIH (ORCPT ); Thu, 10 Mar 2016 21:08:07 -0500 In-Reply-To: (Tom Yan's message of "Thu, 10 Mar 2016 16:15:57 +0800") Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Tom Yan Cc: linux-scsi@vger.kernel.org >>>>> "Tom" == Tom Yan writes: Tom> Hmm, is it originated from: (2^32-1) - (2^32-1)%512 = 4294966784 Tom> bytes = 8388607 (512-byte) blocks = 0x7fffff Yes. Tom> What about SD_MAX_XFER_BLOCKS then? It is merely there to provide a theoretical upper max for the 16 and 32-byte READ/WRITE commands. The block layer would never submit a request that big given all the constraints we have in place (controller segment/scatterlist/max_sectors, etc.). The TRIM/WRITE SAME/UNMAP commands are different in that their payload size differs from the size of the block range they act upon. So we need to artificially constrain their limits. -- Martin K. Petersen Oracle Linux Engineering