public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Andries Brouwer <Andries.Brouwer@cwi.nl>
Cc: "Mike Miller (OS Dev)" <mikem@beardog.cca.cpqcorp.net>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] make kernel ignore bogus partitions
Date: Mon, 08 May 2006 11:00:32 -0400	[thread overview]
Message-ID: <445F5D10.3090401@torque.net> (raw)
In-Reply-To: <20060508072701.GB15941@apps.cwi.nl>

Andries Brouwer wrote:
> On Wed, May 03, 2006 at 04:00:55PM -0500, Mike Miller (OS Dev) wrote:
> 
>>Patch 1/1
>>Sometimes partitions claim to be larger than the reported capacity of a
>>disk device. This patch makes the kernel ignore those partitions.
>>
>>Signed-off-by: Mike Miller <mike.miller@hp.com>
>>Signed-off-by: Stephen Cameron <steve.cameron@hp.com>
> 
> 
>>+		if (from+size-1 > get_capacity(disk)) {
>>+			printk(" %s: p%d exceeds device capacity, ignoring.\n", 
>>+				disk->disk_name, p);
>>+			continue;
>>+		}
> 
> 
> I debated for a while with myself whether I should like or dislike
> such a patch. On the one hand, this partition stuff is rather messy,
> and if you invent strict rules that partitions should satisfy then
> during the transition lots of people will be unhappy, but afterwards
> the stuff may be less messy.
> 
> On the other hand, such changes do indeed make people unhappy.
> Indeed, with this change one of my systems does not boot anymore.
> 
> There can be reasons, or there can have been reasons, for partitions
> larger than the disk. Maybe the disk has a jumper clipping the capacity
> while in other machines such a jumper is unnecessary, or while soon
> after booting the setmax utility is called to set the disk to full
> capacity again.
> Or, while doing forensics on a disk one copies the start to some
> other disk, and that other disk may be smaller.
> Etc.

Andries,
With the creative use of the MODE SELECT SCSI command
one can "short stroke" a disk, making subsequent READ
CAPACITY commands report less than is actually available.
READ and WRITE commands also would be crimped. For
example a 300 GB SCSI disk could be made to report
a capacity of 1 sector. [see sg_format in sg3_utils]

More practically RAID replacement disks may use this
facility if the firmware wants all disks the same
size and a smaller size disk (e.g. 18 GB SCSI disk) is
no longer available.

Without a product manual in which a manufacturer states
what the number of sectors should be, it may not be
obvious short stroking has occurred.


There are other situations I have come across, that can
be made to work if you know what is happening. When I
put a 160 GB PATA disk in an external USB enclosure that
doesn't support 48 bit lba, then I can't access anything
above the 137 (?) GB mark. By arranging my partitions
accordingly (e.g. 3 under, 1 over) the lower partitions
are still useable in the USB enclosure.

> So, it seems that Linux loses a little bit of its power when such things
> are made impossible.

Doug Gilbert

  reply	other threads:[~2006-05-08 15:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-03 21:00 [PATCH] make kernel ignore bogus partitions Mike Miller (OS Dev)
2006-05-08  7:27 ` Andries Brouwer
2006-05-08 15:00   ` Douglas Gilbert [this message]
2006-05-08 15:33   ` David Greaves
2006-05-08 20:20     ` Jan Engelhardt
2006-05-08 20:46       ` reiser4 bug [was Re: 2.6.17-rc3-mm1] Alexander Gran
2006-05-08 23:21         ` Joe Feise
2006-05-09  0:13           ` Alexander Gran
2006-05-09 19:41 ` [PATCH] make kernel ignore bogus partitions Andrew Morton
2006-05-09 22:48   ` Andries Brouwer
2006-05-11 11:00     ` Andrew Morton
2006-05-11 11:51       ` Andries Brouwer
2006-05-11 16:04         ` Mike Miller (OS Dev)
2006-05-11 23:08         ` Daniel Barkalow
2006-05-12 10:32           ` Jan Engelhardt
2006-10-30 19:45             ` Phillip Susi
2006-10-30 21:48               ` Christian Schmidt
2006-05-11 21:47       ` Mike Miller (OS Dev)
2006-05-11 16:17   ` Mike Miller (OS Dev)
2006-05-11 16:27     ` Andrew Morton
2006-05-11 17:09       ` Alan Cox

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=445F5D10.3090401@torque.net \
    --to=dougg@torque.net \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox