Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

[Stefan Richter]

Ronald wrote at linux1394-user:
> Linux doesn't support bigger than 2TB IEEE-1394 disk.
> 
> Will Linux have new driver for this issue?

(Adding Cc: linux-scsi)

As far as I can tell, Linux does support IEEE 1394 disks of any size. 
However, if I'm not mistaken, disks larger than 2 TB require that the 
READ CAPACITY (16) command is used to check the disk's capacity, rather 
than the usual READ CAPACITY (10) command.  Somebody correct me if I'm 
wrong.

By far most firmwares of IEEE 1394/ SBP-2 chipsets implement only the 
RBC (Reduced Block Commands) command set specification, or at least 
claim so in their INQUIRY response.  If I understood correctly, the 
Linux SCSI stack will never send READ CAPACITY (16) to them since this 
command is not included in RBC.

It is only part of the more general SBC (SCSI Block Commands) 
specification.  But Linux won't also send READ CAPACITY (16) to disks 
which claim SBC support, unless they also claim conformance to a 
reasonably recent SCSI revision (I don't remember which one and am too 
lazy to check).  This is because older firmwares may crash if they 
receive READ CAPACITY (16).

Ronald, do you know of a specific series of SBP-2 firmwares which do 
actually support READ CAPACITY (16) properly but are treated by Linux as 
if they wouldn't?  If so, we could add a workaround to our drivers to 
treat them like recent SBC implementations.  We would have to match 
against their firmware_revision field which you get logged in dmesg if 
you load the sbp2 or firewire-sbp2 driver with the module parameter 
workarounds=0x1000.

(Still, I could be mistaken and the problem might be something else than 
which READ CAPACITY flavor to use.  Maybe somebody more familiar with 
the block oriented SCSI command sets could comment.)
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

[Stefan Richter]

Stefan Richter wrote:
> do you know of a specific series of SBP-2 firmwares which do 
> actually support READ CAPACITY (16) properly but are treated by Linux as 
> if they wouldn't?  If so, we could add a workaround to our drivers to 
> treat them like recent SBC implementations.  We would have to match 
> against their firmware_revision field which you get logged in dmesg if 
> you load the sbp2 or firewire-sbp2 driver with the module parameter 
> workarounds=0x1000.

PS:

# modprobe -r sbp2
# modprobe sbp2 workarounds=0x1000
(plug the disk in, wait 5 or 10 seconds or so)
# dmesg

Use firewire-sbp2 instead of sbp2 if your distribution already uses the 
newer firewire drivers which are alternatively available in recent 
kernel versions.  E.g. on Fedora.
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

[James Bottomley]

On Mon, 2009-05-04 at 16:45 +0200, Stefan Richter wrote:
> Ronald wrote at linux1394-user:
> > Linux doesn't support bigger than 2TB IEEE-1394 disk.
> > 
> > Will Linux have new driver for this issue?
> 
> (Adding Cc: linux-scsi)
> 
> As far as I can tell, Linux does support IEEE 1394 disks of any size. 
> However, if I'm not mistaken, disks larger than 2 TB require that the 
> READ CAPACITY (16) command is used to check the disk's capacity, rather 
> than the usual READ CAPACITY (10) command.  Somebody correct me if I'm 
> wrong.
> 
> By far most firmwares of IEEE 1394/ SBP-2 chipsets implement only the 
> RBC (Reduced Block Commands) command set specification, or at least 
> claim so in their INQUIRY response.  If I understood correctly, the 
> Linux SCSI stack will never send READ CAPACITY (16) to them since this 
> command is not included in RBC.

That's true ... but not quite the way we work.  There's a standard
defined return for READ CAPACITY(10) which means ... I have more
sectors, please use READ CAPACITY (16).  If we get that return, we'll
try again with READ CAPACITY (16) regardless of whether the device says
it's only RBC or not.

> It is only part of the more general SBC (SCSI Block Commands) 
> specification.  But Linux won't also send READ CAPACITY (16) to disks 
> which claim SBC support, unless they also claim conformance to a 
> reasonably recent SCSI revision (I don't remember which one and am too 
> lazy to check).  This is because older firmwares may crash if they 
> receive READ CAPACITY (16).

Again, no.  Standards conformance alters the way we probe.  Recently we
altered this at Intel's request because some details of thin
provisioning (TRIM support) are only available in READ CAPACITY (16)
response.  So, since 2.6.30 we lead with READ CAPACITY (16) for recent
standard supporting devices.  For all others, we lead with READ CAPACITY
(10) but we'd still move to READ CAPACITY (10) if we get the
conventional I'm bigger than READ CAPACITY (10) will support return.

> Ronald, do you know of a specific series of SBP-2 firmwares which do 
> actually support READ CAPACITY (16) properly but are treated by Linux as 
> if they wouldn't?  If so, we could add a workaround to our drivers to 
> treat them like recent SBC implementations.  We would have to match 
> against their firmware_revision field which you get logged in dmesg if 
> you load the sbp2 or firewire-sbp2 driver with the module parameter 
> workarounds=0x1000.
> 
> (Still, I could be mistaken and the problem might be something else than 
> which READ CAPACITY flavor to use.  Maybe somebody more familiar with 
> the block oriented SCSI command sets could comment.)

James

Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

[Matthew Wilcox]

On Mon, May 04, 2009 at 02:51:26PM +0000, James Bottomley wrote:
> > It is only part of the more general SBC (SCSI Block Commands) 
> > specification.  But Linux won't also send READ CAPACITY (16) to disks 
> > which claim SBC support, unless they also claim conformance to a 
> > reasonably recent SCSI revision (I don't remember which one and am too 
> > lazy to check).  This is because older firmwares may crash if they 
> > receive READ CAPACITY (16).
> 
> Again, no.  Standards conformance alters the way we probe.  Recently we
> altered this at Intel's request

Um.  My request, not Intel's.  I put forward the argument that T10 were
adding more and more features that were reported by READ CAPACITY 16
(and obviously can't be added to RC10).  You appeared convinced by
the argument.

I don't know how 'Intel' makes a request.  I can only assume there's
a process that involves meetings.  And stakeholders.  And buy-ins.
Let's never go there.

It'd be more honest to say that T10 are forcing Linux to try RC16 in
preference to RC10, even for devices <2TB.  If they put bits like TPE
in the VPD pages instead of the return from RC16, I don't think Linux
would care about RC16.

> because some details of thin
> provisioning (TRIM support) are only available in READ CAPACITY (16)
> response.

As far as I know, Intel has no stake in SCSI's Thin Provisioning.
I'm just trying to be a good Linux citizen and sort out issues relating
to TRIM while I'm implementing TRIM.  If I get this kind of response,
I'm going to stop doing that.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

[Stefan Richter]

OK, so the upshot is:

   - The usually used commands READ CAPACITY (10), READ (10), WRITE (10)
     support 32 bits wide logical block addresses (LBAs), which is
     sufficient for up to 2 TB at the currently ubiquitously used block
     size of 512 bytes.

   - Linux will use READ CAPACITY (16), READ (16), WRITE (16) if the disk
     behaves like an SBC disk, particularly, if the disk responds with
     0xffffffff to READ CAPACITY (10) like defined in SBC.  This will
     happen regardless whether the disk showed itself as SBC or RBC disk
     in the INQUIRY response (which comes before the capacity is read).
     So the fact that many IEEE 1394 disks show themselves as RBC in the
     INQUIRY response doesn't matter in this regard, what matters is
     the implemented READ CAPACITY behavior of the disk.

     READ CAPACITY (16), READ (16), WRITE (16) have 64 bits wide LBA
     fields and thus enable disk sizes of more than 2 TB.

   - Furthermore, Linux will use READ CAPACITY (16) even before having
     tried READ CAPACITY (10) under some special circumstances, which
     also depend on the kernel version.  This however is less relevant to
     the problem at hand.

And lastly, one thing which I almost forgot:

On 32 bit CPU architectures, it is necessary that the kernel was 
compiled with the option "Support for large block devices and files" 
(LBD) switched on.  My guess is that all commonly used Linux 
distributions for 32bit systems do have this option enabled in their 
standard kernel packages --- at least the more recent ones.  It's not an 
issue with 64 bit CPU architectures.
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: Linux doesn't support bigger than 2TB IEEE-1394 disk

[Stefan Richter]

James Bottomley wrote on 2009-05-04:
> On Mon, 2009-05-04 at 16:45 +0200, Stefan Richter wrote:
>> Ronald wrote at linux1394-user:
>>> Linux doesn't support bigger than 2TB IEEE-1394 disk.
>>>
>>> Will Linux have new driver for this issue?
>> (Adding Cc: linux-scsi)
>>
>> As far as I can tell, Linux does support IEEE 1394 disks of any size. 
>> However, if I'm not mistaken, disks larger than 2 TB require that the 
>> READ CAPACITY (16) command is used to check the disk's capacity, rather 
>> than the usual READ CAPACITY (10) command.  Somebody correct me if I'm 
>> wrong.
>>
>> By far most firmwares of IEEE 1394/ SBP-2 chipsets implement only the 
>> RBC (Reduced Block Commands) command set specification, or at least 
>> claim so in their INQUIRY response.  If I understood correctly, the 
>> Linux SCSI stack will never send READ CAPACITY (16) to them since this 
>> command is not included in RBC.
> 
> That's true ... but not quite the way we work.  There's a standard
> defined return for READ CAPACITY(10) which means ... I have more
> sectors, please use READ CAPACITY (16).  If we get that return, we'll
> try again with READ CAPACITY (16) regardless of whether the device says
> it's only RBC or not.

I obviously missed one other fact:

Initiator drivers need to tell the Linux SCSI core what the maximum 
length of commands is that the driver is able to send to targets.  Alas 
our SBP-2 drivers do not specifiy a value for this (struct 
Scsi_Host.max_cmd_len) and hence the core will send at most 12 bytes 
long command blocks.  But for disks > 2TB, we need 16 bytes long command 
blocks.

I need to fix the SBP-2 drivers to set the limit correctly.  This will 
be a little more than one-liners though, I guess, because we need to 
check a target capability datum before we set the length limit.

Stay tuned.
-- 
Stefan Richter
-=====-==--= -==- ===-=
http://arcgraph.de/sr/

[PATCH] firewire: sbp2: add support for disks >2 TB (and CBSs >12 bytes)

[Stefan Richter]

I wrote:
> I need to fix the SBP-2 drivers to set the limit correctly.  This will 
> be a little more than one-liners though, I guess, because we need to 
> check a target capability datum before we set the length limit.

No, we don't need to check anything.  The transport allows for
arbitrarily sized command descriptor blocks.

---------- 8< ----------

We forgot to set Scsi_Host.max_cmd_len.  Therefore SCSI core sent at
most 12 bytes long commands to FireWire targets.  Among else, this
prevented support of disks larger than 2 TB.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/firewire/sbp2.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: b/drivers/firewire/sbp2.c
===================================================================
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -1146,6 +1146,12 @@ static int sbp2_probe(struct device *dev
 	if (fw_device_enable_phys_dma(device) < 0)
 		goto fail_shost_put;
 
+	/*
+	 * SBP-2 does not impose limits on the CDB length.  Targets may have
+	 * limits, but this is going to be reported at the command set level.
+	 */
+	shost->max_cmd_len = SCSI_MAX_VARLEN_CDB_SIZE;
+
 	if (scsi_add_host(shost, &unit->device) < 0)
 		goto fail_shost_put;
 


-- 
Stefan Richter
-=====-==--= -==- ===-=
http://arcgraph.de/sr/

[PATCH] ieee1394: sbp2: add support for disks >2 TB (and CBSs >12 bytes)

[Stefan Richter]

We forgot to set Scsi_Host.max_cmd_len.  Therefore SCSI core sent at
most 12 bytes long commands to FireWire targets.  Among else, this
prevented support of disks larger than 2 TB.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/sbp2.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: b/drivers/ieee1394/sbp2.c
===================================================================
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -881,6 +881,12 @@ static struct sbp2_lu *sbp2_alloc_device
 
 	shost->hostdata[0] = (unsigned long)lu;
 
+	/*
+	 * SBP-2 does not impose limits on the CDB length.  Targets may have
+	 * limits, but this is going to be reported at the command set level.
+	 */
+	shost->max_cmd_len = SCSI_MAX_VARLEN_CDB_SIZE;
+
 	if (!scsi_add_host(shost, &ud->device)) {
 		lu->shost = shost;
 		return lu;

-- 
Stefan Richter
-=====-==--= -==- ===-=
http://arcgraph.de/sr/

[PATCH update] firewire: sbp2: add support for disks >2 TB (and 16 bytes long CDBs)

[Stefan Richter]

Increase the command ORB data structure to transport up to 16 bytes long
CDBs (instead of 12 bytes), and tell the SCSI mid layer about it.  This
is notably necessary for READ CAPACITY(16) and friends, i.e. support of
large disks.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/firewire/sbp2.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Index: b/drivers/firewire/sbp2.c
===================================================================
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -201,6 +201,12 @@ static struct fw_device *target_device(s
 #define SBP2_CYCLE_LIMIT		(0xc8 << 12)	/* 200 125us cycles */
 
 /*
+ * There is no transport protocol limit to the CDB length,  but we implement
+ * a fixed length only.  16 bytes is enough for disks larger than 2 TB.
+ */
+#define SBP2_MAX_CDB_SIZE		16
+
+/*
  * The default maximum s/g segment size of a FireWire controller is
  * usually 0x10000, but SBP-2 only allows 0xffff. Since buffers have to
  * be quadlet-aligned, we set the length limit to 0xffff & ~3.
@@ -312,7 +318,7 @@ struct sbp2_command_orb {
 		struct sbp2_pointer next;
 		struct sbp2_pointer data_descriptor;
 		__be32 misc;
-		u8 command_block[12];
+		u8 command_block[SBP2_MAX_CDB_SIZE];
 	} request;
 	struct scsi_cmnd *cmd;
 	scsi_done_fn_t done;
@@ -1146,6 +1152,8 @@ static int sbp2_probe(struct device *dev
 	if (fw_device_enable_phys_dma(device) < 0)
 		goto fail_shost_put;
 
+	shost->max_cmd_len = SBP2_MAX_CDB_SIZE;
+
 	if (scsi_add_host(shost, &unit->device) < 0)
 		goto fail_shost_put;
 

-- 
Stefan Richter
-=====-==--= -==- ====-
http://arcgraph.de/sr/

[PATCH update] ieee1394: sbp2: add support for disks >2 TB (and 16 bytes long CDBs)

[Stefan Richter]

Increase the command ORB data structure to transport up to 16 bytes long
CDBs (instead of 12 bytes), and tell the SCSI mid layer about it.  This
is notably necessary for READ CAPACITY(16) and friends, i.e. support of
large disks.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/sbp2.c |    1 +
 drivers/ieee1394/sbp2.h |    8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

Index: b/drivers/ieee1394/sbp2.c
===================================================================
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -880,6 +880,7 @@ static struct sbp2_lu *sbp2_alloc_device
 	}
 
 	shost->hostdata[0] = (unsigned long)lu;
+	shost->max_cmd_len = SBP2_MAX_CDB_SIZE;
 
 	if (!scsi_add_host(shost, &ud->device)) {
 		lu->shost = shost;
Index: b/drivers/ieee1394/sbp2.h
===================================================================
--- a/drivers/ieee1394/sbp2.h
+++ b/drivers/ieee1394/sbp2.h
@@ -25,6 +25,12 @@
 #define SBP2_DEVICE_NAME		"sbp2"
 
 /*
+ * There is no transport protocol limit to the CDB length,  but we implement
+ * a fixed length only.  16 bytes is enough for disks larger than 2 TB.
+ */
+#define SBP2_MAX_CDB_SIZE		16
+
+/*
  * SBP-2 specific definitions
  */
 
@@ -51,7 +57,7 @@ struct sbp2_command_orb {
 	u32 data_descriptor_hi;
 	u32 data_descriptor_lo;
 	u32 misc;
-	u8 cdb[12];
+	u8 cdb[SBP2_MAX_CDB_SIZE];
 } __attribute__((packed));
 
 #define SBP2_LOGIN_REQUEST		0x0

-- 
Stefan Richter
-=====-==--= -==- ====-
http://arcgraph.de/sr/