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: 22+ 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: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 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.