From: Andrew Clausen <clausen@gnu.org>
To: John Bradford <john@grabjohn.com>
Cc: Arjan van de Ven <arjanv@redhat.com>,
Andries Brouwer <aebr@win.tue.nl>,
Szakacsits Szabolcs <szaka@sienet.hu>,
Apurva Mehta <apurva@gmx.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
bug-parted@gnu.org
Subject: Re: Disk Geometries reported incorrectly on 2.6.0-testX
Date: Mon, 1 Dec 2003 10:51:11 +1100 [thread overview]
Message-ID: <20031130235111.GB464@gnu.org> (raw)
In-Reply-To: <200311301040.hAUAePk6000149@81-2-122-30.bradfords.org.uk>
On Sun, Nov 30, 2003 at 10:40:25AM +0000, John Bradford wrote:
> > EFI GPT has some severe downsides (like requiring the last sector on
> > disk, which in linux may not be accessible if the total number of
> > sectors is not a multiple of 2, and making dd of one disk to another
> > impossible if the second one is bigger)
>
> EFI GPT is also a far more elaborate scheme than is necessary for a
> lot of installations.
Is this a problem?
> My 'requirements' are:
>
> * Good magic
>
> We have seen support for not very widely used partitioning schemes
> broken in the past when other schemes are checked for ahead of them.
> A simple scheme with well defined magic values reduces this risk.
I think magic doesn't belong in partition tables. I like probing.
Having the same data stored in two places makes things hairy
if you don't know how to resolve inconsistencies.
> * Simple
>
> The code for some of the partitioning schemes is full of workarounds
> for different implementations. Added complexity, and more variations
> increase the likelyhood of bugs.
If you're not interested in work-arounds, why not use LVM?
> * All partition information stored in one partition table
>
> Linked lists make re-arranging partitions, and backing up the
> partition table more difficult.
I don't think it's very difficult, but I agree that tables are nice
and simple.
Cheers,
Andrew
next prev parent reply other threads:[~2003-11-30 23:46 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-28 4:58 Disk Geometries reported incorrectly on 2.6.0-testX Apurva Mehta
2003-11-28 14:24 ` Andries Brouwer
2003-11-29 2:22 ` Andrew Clausen
2003-11-29 5:16 ` Szakacsits Szabolcs
2003-11-29 9:18 ` Sven Luther
2003-11-29 12:41 ` Andries Brouwer
2003-11-30 11:44 ` Szakacsits Szabolcs
2003-11-30 15:19 ` Andries Brouwer
2003-11-29 12:34 ` Andries Brouwer
2003-11-29 13:50 ` John Bradford
2003-11-29 14:04 ` Stefan Smietanowski
2003-11-29 17:01 ` Sven Luther
2003-11-29 22:14 ` Andries Brouwer
2003-11-29 22:44 ` Sven Luther
2003-11-30 0:39 ` Andries Brouwer
2003-11-30 9:35 ` Sergey Vlasov
2003-11-29 22:31 ` Andrew Clausen
2003-11-30 8:57 ` Arjan van de Ven
2003-11-30 7:38 ` Szakacsits Szabolcs
2003-11-30 10:40 ` John Bradford
2003-11-30 11:24 ` Sven Luther
2003-11-30 13:48 ` John Bradford
2003-11-30 17:22 ` Sven Luther
2003-11-30 23:51 ` Andrew Clausen [this message]
2003-11-30 22:54 ` Andrew Clausen
2003-11-29 22:27 ` Andrew Clausen
2003-11-30 0:34 ` Andries Brouwer
2003-11-30 11:10 ` Szakacsits Szabolcs
2003-11-30 13:26 ` Andries Brouwer
2003-11-30 12:34 ` Szakacsits Szabolcs
2003-11-30 15:46 ` Andries Brouwer
2003-11-29 22:33 ` Andrew Clausen
2003-11-30 9:16 ` Szakacsits Szabolcs
2003-12-03 11:05 ` Andrew Clausen
2003-12-03 11:28 ` Szakacsits Szabolcs
2003-12-03 11:54 ` Andrew Clausen
2003-12-03 13:07 ` Szakacsits Szabolcs
2003-12-03 23:27 ` Andrew Clausen
2003-12-03 21:55 ` Szakacsits Szabolcs
2003-12-03 23:47 ` bill davidsen
[not found] <200311300220.hAU2K0dr019280@sunrise.pg.gda.pl>
2003-11-30 2:22 ` Andrzej Krzysztofowicz
2003-11-30 13:13 ` Andries Brouwer
2003-11-30 13:58 ` John Bradford
-- strict thread matches above, loose matches on Subject: below --
2003-11-30 7:08 Norman Diamond
2003-11-30 7:08 Norman Diamond
2003-11-30 12:49 ` Andries Brouwer
2003-12-03 11:06 ` Andrew Clausen
2003-12-03 14:42 ` Andries Brouwer
2003-12-03 23:11 ` Andrew Clausen
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=20031130235111.GB464@gnu.org \
--to=clausen@gnu.org \
--cc=aebr@win.tue.nl \
--cc=apurva@gmx.net \
--cc=arjanv@redhat.com \
--cc=bug-parted@gnu.org \
--cc=john@grabjohn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=szaka@sienet.hu \
/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.