From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "Jurzitza, Dieter" <DJurzitza@harmanbecker.com>,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Jeff Mahoney <jeffm@suse.com>,
sparclinux@vger.kernel.org
Subject: Re: fix 2.4.33.3 / sun partition size
Date: Tue, 12 Sep 2006 17:17:08 -0500 [thread overview]
Message-ID: <1158099428.13234.232.camel@localhost.localdomain> (raw)
In-Reply-To: <20060912191736.GG541@1wt.eu>
On Tue, 2006-09-12 at 21:17 +0200, Willy Tarreau wrote:
> On Tue, Sep 12, 2006 at 01:23:56PM +0200, Jurzitza, Dieter wrote:
> > Kernel: 2.4.33
> >
> > Issue: really fix size display for sun partitions larger than 1TByte
> >
> > Signed off by: Dieter Jurzitza DJurzitza@HarmanBecker.com
> >
> > Problem: the last fix introduced by Jeff Mahoney for kernel 2.6 was not complete for kernel 2.4 (as applied)
> > I found out that add_gd_partition is called by any type of partition (2.4). add_gd_partition is defined as add_gd_partition (int, int), what makes no sense to me as negative numbers should never occur here. As long as add_gd_partition is not changed to add_gd_partition (unsigned, unsigned), /proc/partitions will keep showing negative numbers.
>
> It seems fair. David, what's your opinion ?
>
> > If ever someone could look into this, within the different partition type files in linux/fs/partitions the parameters to add_gd_partitions seem to be chosen arbitrarily between int, unsigned and unsigned long, whatever seemed to be appropriate, I think it would make sense to get consistent parameters to add_gd_partition from all partition types here.
> > Especially if one takes into account that sizeof (long) and sizeof (int) may differ significantly i. e. on sparc.
>
> It would really depend on the on-disk format. If the partition table really
> stores 32 bit ints for sector counts, there's no point switching from ints
> to longs. But if it already stores 64 bits, then we're limiting it to 2 TB
> with 32 bit ints. I haven't checked the code right now, so I don't know. I
> hope Davem will enlighten us on this matter.
I think Davem may be on vacation...
~spot
--
Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260
"We must not confuse dissent with disloyalty. We must remember always
that accusation is not proof and that conviction depends upon evidence
and due process of law. We will not walk in fear, one of another. We
will not be driven by fear into an age of unreason, if we dig deep in
our history and our doctrine, and remember that we are not descended
from fearful men -- not from men who feared to write, to speak, to
associate and to defend causes that were, for the moment, unpopular."
-- Edward R. Murrow, March 9, 1954
next prev parent reply other threads:[~2006-09-12 22:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-12 11:23 fix 2.4.33.3 / sun partition size Jurzitza, Dieter
2006-09-12 19:17 ` Willy Tarreau
2006-09-12 22:17 ` Tom 'spot' Callaway [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-09-13 5:40 AW: " Jurzitza, Dieter
2006-09-16 21:33 ` Willy Tarreau
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=1158099428.13234.232.camel@localhost.localdomain \
--to=tcallawa@redhat.com \
--cc=DJurzitza@harmanbecker.com \
--cc=davem@davemloft.net \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=w@1wt.eu \
/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