public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Extended partition mapping wrong size
Date: Tue, 6 Apr 2010 13:47:07 +0200	[thread overview]
Message-ID: <20100406114706.GA30340@nb.net.home> (raw)
In-Reply-To: <4BB0D12B.6060701@cfl.rr.com>

On Mon, Mar 29, 2010 at 12:11:23PM -0400, Phillip Susi wrote:
> I've been investigating a problem I ran into trying to create partitions
> in sector mode and found that the first logical partition can not begin
> on the very first sector of the extended partition, immediately
> following the EBR.  This apparently is because the kernel creates a dev
> node to represent the extended partition and sizes it to two sectors.

This is probably kernel bug. It's really insane that the extended
pseudo partition overflows to the next logical partition.

> could have sworn that the kernel did not used to create a device for the
> extended partition itself, but I wondered why it was 2 sectors long.  I
> found this:
> 
> from fs/partitions/msdos.c:
> 
>             /* prevent someone doing mkfs or mkswap on an
>                extended partition, but leave room for LILO */
>             put_partition(state, slot, start, size == 1 ? 1 : 2);
>
> This appears to set the size of the device to 2 sectors, unless the
> extended partition is only 1 sector long.  Shouldn't the size be
> whatever length there is between the start of the extended partition,
> and the first logical partition it contains?  So if there are 63 sectors
> there, as is the usual case when using cylinder alignment, then the

 Please no. I think the size should not be more than 2 sectors (1024
 bytes). The current concept works for years and we have in userspace 
 /etc/partitions parsers that use "if (blocks <= 1)" to detect
 extended partitions.

 The other problem are mkfs programs, the space used for alignment
 could be 1MiB (or more) -- it's enough many mkfs programs.


 BTW, Linux does not use this policy for the others nested partition
 tables (e.g. Solaris, BSD, Minix, ...). The extended dos partition
 table is exception. The primary partitions for the others nested PT
 are exported to the system with its real size :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2010-04-06 11:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 16:11 Extended partition mapping wrong size Phillip Susi
2010-04-06 11:47 ` Karel Zak [this message]
2010-04-06 13:58   ` Phillip Susi
2010-04-06 15:33     ` Karel Zak
2010-04-06 16:06       ` Phillip Susi

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=20100406114706.GA30340@nb.net.home \
    --to=kzak@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psusi@cfl.rr.com \
    /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