All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Frank Borich <Frank_Borich@us.xyratex.com>
Cc: "tester7 A." <benew666@hotmail.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	tech@storageone.co.kr
Subject: RE: QLA2300, Infortrand and LBD?
Date: 28 Jul 2004 10:17:50 -0400	[thread overview]
Message-ID: <1091024272.2225.32.camel@mulgrave> (raw)
In-Reply-To: <47F3C2BE74738E4683574107469DFA204CC855@XYUSEX01.xyus.xyratex.com>

On Wed, 2004-07-28 at 09:46, Frank Borich wrote:
> Looking at an FC trace on an Infortrend controller I have, shows that
> for a LUN 3586680 MB in size, the LBA is B5D3BFFF in the "RETURNED
> LOGICAL BLOCK ADDRESS FIELD" 
> and with in the "BLOCK LENGTH IN BYTES FIELD" field is 200h , ( B5D3BFFF
> * 200h =  approx. 1.6 TB). Seems that infortrend does NOT respond
> properly to READ_CAPACITY_10, at least in my case. 

Well 3586680 MB == 0x1b5d3bfff * 0x200

so I think you can see where the returned figure is coming from...

Infortrends should be made aware of the problem so they can do a bios
upgrade.  I suspect that even if the array returned the correct capacity
it would be unable to process the READ/WRITE(16) commands necessary to
reach it anyway, so their "fix" may be to tell you that no individual
luns can be configured beyond 2TB.

> James, this may be a dumb question, please excuse my ignorance of the
> internals of the scsi subsystem, 
> but is there a plan to implement LBD support in the 2.4 tree ?

The problem is not just in SCSI, it permeates the block layer.  I don't
think there's much point backporting LBD to 2.4, although many vendor
trees have it.

James



  reply	other threads:[~2004-07-28 14:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-28 13:46 QLA2300, Infortrand and LBD? Frank Borich
2004-07-28 14:17 ` James Bottomley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-07-29 13:17 Frank Borich
2004-06-22  0:31 tester7 A.
2004-06-21 14:28 Frank Borich
2004-06-21 14:32 ` James Bottomley
2004-06-21 13:41 Frank Borich
2004-06-21  1:24 tester7 A.
2004-06-20  8:43 tester7 A.
2004-06-21 14:09 ` James Bottomley

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=1091024272.2225.32.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=Frank_Borich@us.xyratex.com \
    --cc=benew666@hotmail.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tech@storageone.co.kr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.