From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Matthew Wilcox <matthew@wil.cx>, Ronald <Ronald@ioi.com.tw>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
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 20:22:42 +0200 [thread overview]
Message-ID: <49FF3272.5040406@s5r6.in-berlin.de> (raw)
In-Reply-To: <20090504150616.GY8822@parisc-linux.org>
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/
next prev parent reply other threads:[~2009-05-04 18:23 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 ` Linux doesn't support bigger than 2TB IEEE-1394 disk Stefan Richter
2009-05-04 14:49 ` Stefan Richter
2009-05-04 14:51 ` James Bottomley
2009-05-04 15:06 ` Matthew Wilcox
2009-05-04 18:22 ` Stefan Richter [this message]
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=49FF3272.5040406@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Ronald@ioi.com.tw \
--cc=linux-scsi@vger.kernel.org \
--cc=linux1394-user@lists.sourceforge.net \
--cc=matthew@wil.cx \
/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