From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Ronald <Ronald@ioi.com.tw>
Cc: linux1394-user@lists.sourceforge.net, linux-scsi@vger.kernel.org
Subject: Re: Linux doesn't support bigger than 2TB IEEE-1394 disk
Date: Mon, 04 May 2009 16:45:14 +0200 [thread overview]
Message-ID: <49FEFF7A.3090603@s5r6.in-berlin.de> (raw)
In-Reply-To: <85681F9DCBFF144DA59C70D83EBC1DA2E1EDE7@EIOISER.ioi.com.tw>
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/
next parent reply other threads:[~2009-05-04 14:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <85681F9DCBFF144DA59C70D83EBC1DA2E1EDE7@EIOISER.ioi.com.tw>
2009-05-04 14:45 ` Stefan Richter [this message]
2009-05-04 14:49 ` Linux doesn't support bigger than 2TB IEEE-1394 disk Stefan Richter
2009-05-04 14:51 ` James Bottomley
2009-05-04 15:06 ` Matthew Wilcox
2009-05-04 18:22 ` Stefan Richter
2009-06-29 18:32 ` Stefan Richter
2009-06-29 20:01 ` [PATCH] firewire: sbp2: add support for disks >2 TB (and CBSs >12 bytes) Stefan Richter
2009-06-29 20:02 ` [PATCH] ieee1394: " Stefan Richter
2009-06-30 18:27 ` [PATCH update] firewire: sbp2: add support for disks >2 TB (and 16 bytes long CDBs) Stefan Richter
2009-06-30 18:28 ` [PATCH update] ieee1394: " Stefan Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49FEFF7A.3090603@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=Ronald@ioi.com.tw \
--cc=linux-scsi@vger.kernel.org \
--cc=linux1394-user@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox