All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Karel Zak <kzak@redhat.com>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Extended partition mapping wrong size
Date: Tue, 6 Apr 2010 09:58:39 -0400	[thread overview]
Message-ID: <4BBB3E0F.1030309@cfl.rr.com> (raw)
In-Reply-To: <20100406114706.GA30340@nb.net.home>

On 4/6/2010 7:47 AM, Karel Zak wrote:
> This is probably kernel bug. It's really insane that the extended
> pseudo partition overflows to the next logical partition.

Indeed.

>  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.

Could you elaborate a bit on this?  What programs have such tests and
what would they do differently if it were larger?

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

What's wrong with that?  If you REALLY want to, there's no reason you
can't create a tiny fs there.  Then again, I could swear that once upon
a time the kernel simply did not bother creating a dev node for the
extended partition, and this seems to be a hack that was put in to make
it easy for LILO to install to one.  Personally I'd prefer going back to
the old behavior of just not having a useless device there.

>  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 :-)

Indeed, also the hidden space in the logical partitions is also not
exposed, otherwise you would have two dev nodes per logical partition.

  reply	other threads:[~2010-04-06 13:58 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
2010-04-06 13:58   ` Phillip Susi [this message]
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=4BBB3E0F.1030309@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=kzak@redhat.com \
    --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 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.