public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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/

  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