From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: possible auto-partition bug? (linux-2.4.20-8)
Date: Fri, 15 Aug 2003 19:15:44 -0700 [thread overview]
Message-ID: <20030816021544.GD3479@pegasys.ws> (raw)
In-Reply-To: <20030815222304.A3272@pclin040.win.tue.nl>
On Fri, Aug 15, 2003 at 10:23:04PM +0200, Andries Brouwer wrote:
> On Fri, Aug 15, 2003 at 01:55:59PM -0400, Pete Nishimoto wrote:
>
> > My name is Pete Nishimoto and I work for Sun Microsystems
> > as a linux device driver developer, currently working with
> > RedHat 9.0 (2.4.20-8) and I believe I have found a problem
> > with the partitioning logic and the pager, which I've
> > detailed below. I look forward to any replies/comments
> > and thanks in advance to all who review/read this.
>
> Hi. You sent a long story, but at first sight it seems not relevant
> for this linux-kernel mailing list.
>
> A disk is made by a manufacturer, and has a number of sectors that we
> must regard as given. If a filesystem is created on this disk then
> often the disk size will turn out not to be precisely an integral
> number of filesystem blocks.
>
> Many people first partition the disk in some more or less arbitrary way.
> Partitions may belong to other operating systems. Again we have no control.
>
> In short, absolutely nothing is wrong if a disk, or a partition, has a size
> that is not an integral number of filesystem blocks.
>
> You talk about badblocks, but that is a userspace utility. If something
> is wrong with it, that is not a kernel matter. Moreover, this utility
> allows one to specify blocksize and last block to test.
>
> So - the relevance to the kernel is not clear to me.
>
> Concerning "RedHat 9.0 (2.4.20-8)" - discussion about vendor specific kernels
> is probably best done on vendor lists.
I can see no relevance to the kernel here.
With the advent of zone recording only sector size, total
sector count and head count have any meaning and head count
is often false so that other geometry numbers will fit into
specified field sizes. You cannot fit 255 heads in a half
height 3.5" drive. Therefore cylinder boundaries are
illusory and should be ignored when partitioning if the
partition table allows LBA addressing.
Partition definition is not a kernel function. It is user space.
badblocks is, as Andries reports, user space, not kernel.
If you read the manpage for badblocks you will see
-b block-size
Specify the size of blocks in bytes.
So even badblocks doesn't need changing to work with
partitions having (sector_count % 8 != 0).
This sounds like an install script problem to me.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt
prev parent reply other threads:[~2003-08-16 2:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-15 17:55 possible auto-partition bug? (linux-2.4.20-8) Pete Nishimoto
2003-08-15 20:23 ` Andries Brouwer
2003-08-16 2:15 ` jw schultz [this message]
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=20030816021544.GD3479@pegasys.ws \
--to=jw@pegasys.ws \
--cc=linux-kernel@vger.kernel.org \
/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