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
next prev parent 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