From: Andrew Morton <akpm@linux-foundation.org>
To: mike.miller@hp.com
Cc: "Mike Miller (OS Dev)" <mikem@beardog.cca.cpqcorp.net>,
jens.axboe@oracle.com, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, gregkh@novell.com
Subject: Re: [Patch 1/2] cciss: fix for 2TB support
Date: Wed, 21 Feb 2007 19:14:27 -0800 [thread overview]
Message-ID: <20070221191427.9b7cf4b0.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070221211039.GA2672@beardog.cca.cpqcorp.net>
On Wed, 21 Feb 2007 15:10:39 -0600 "Mike Miller (OS Dev)" <mikem@beardog.cca.cpqcorp.net> wrote:
> Patch 1/2
>
> This patch changes the way we determine if a logical volume is larger than 2TB. The
> original test looked for a total_size of 0. Originally we added 1 to the total_size.
> That would make our read_capacity return size 0 for >2TB lv's. We assumed that we
> could not have a lv size of 0 so it seemed OK until we were in a clustered system. The
> backup node would see a size of 0 due to the reservation on the drive. That caused
> the driver to switch to 16-byte CDB's which are not supported on older controllers.
> After that everything was broken.
> It may seem petty but I don't see the value in trying to determine if the LBA is
> beyond the 2TB boundary. That's why when we switch we use 16-byte CDB's for all
> read/write operations.
> Please consider this for inclusion.
>
> ...
>
> + if (total_size == 0xFFFFFFFF) {
I seem to remember having already questioned this. total_size is sector_t, which
can be either 32-bit or 64-bit. Are you sure that comparison works as
intended in both cases?
> + if(total_size == 0xFFFFFFFF) {
> cciss_read_capacity_16(cntl_num, i, 0,
> &total_size, &block_size);
> hba[cntl_num]->cciss_read = CCISS_READ_16;
Here too.
next prev parent reply other threads:[~2007-02-22 3:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-21 21:10 [Patch 1/2] cciss: fix for 2TB support Mike Miller (OS Dev)
2007-02-22 3:14 ` Andrew Morton [this message]
2007-02-22 7:31 ` [PATCH] Speedup divides by cpu_power in scheduler Eric Dumazet
2007-02-22 7:56 ` Ingo Molnar
2007-02-22 8:19 ` [PATCH, take 2] " Eric Dumazet
2007-02-22 8:19 ` Ingo Molnar
2007-02-22 16:51 ` [Patch 1/2] cciss: fix for 2TB support Mike Miller (OS Dev)
2007-02-22 21:24 ` Andrew Morton
2007-02-22 21:41 ` James Bottomley
2007-02-22 22:02 ` Mike Miller (OS Dev)
2007-02-22 22:06 ` James Bottomley
2007-02-23 20:52 ` Mike Miller (OS Dev)
2007-02-24 6:35 ` Andrew Morton
2007-02-22 20:18 ` Mike Miller (OS Dev)
2007-02-22 21:22 ` Miller, Mike (OS Dev)
2007-02-22 21:22 ` Miller, Mike (OS Dev)
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=20070221191427.9b7cf4b0.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=gregkh@novell.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mike.miller@hp.com \
--cc=mikem@beardog.cca.cpqcorp.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 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.