All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Jurzitza, Dieter" <DJurzitza@harmanbecker.com>, davem@davemloft.net
Cc: 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 19:17:36 +0000	[thread overview]
Message-ID: <20060912191736.GG541@1wt.eu> (raw)
In-Reply-To: <DA6197CAE190A847B662079EF7631C06015692C2@OEKAW2EXVS03.hbi.ad.harman.com>

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.

> Take care
> 
> 
> Dieter Jurzitza

Thanks,
Willy


WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu>
To: "Jurzitza, Dieter" <DJurzitza@harmanbecker.com>, davem@davemloft.net
Cc: 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 21:17:36 +0200	[thread overview]
Message-ID: <20060912191736.GG541@1wt.eu> (raw)
In-Reply-To: <DA6197CAE190A847B662079EF7631C06015692C2@OEKAW2EXVS03.hbi.ad.harman.com>

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.

> Take care
> 
> 
> Dieter Jurzitza

Thanks,
Willy


  reply	other threads:[~2006-09-12 19:17 UTC|newest]

Thread overview: 12+ 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 11:23 ` Jurzitza, Dieter
2006-09-12 19:17 ` Willy Tarreau [this message]
2006-09-12 19:17   ` Willy Tarreau
2006-09-12 22:17   ` Tom 'spot' Callaway
2006-09-12 22:17     ` Tom 'spot' Callaway
2006-09-13  5:06 ` AW: " Jurzitza, Dieter
2006-09-13  5:06   ` Jurzitza, Dieter
2006-09-13  5:40 ` Jurzitza, Dieter
2006-09-13  5:40   ` Jurzitza, Dieter
2006-09-16 21:33   ` Willy Tarreau
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=20060912191736.GG541@1wt.eu \
    --to=w@1wt.eu \
    --cc=DJurzitza@harmanbecker.com \
    --cc=davem@davemloft.net \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@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 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.