From: Theodore Tso <tytso@mit.edu>
To: Rene Herman <rene.herman@gmail.com>
Cc: Al Boldi <a1426z@gawab.com>,
linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFH] Partition table recovery
Date: Mon, 23 Jul 2007 09:48:35 -0400 [thread overview]
Message-ID: <20070723134835.GC19927@thunk.org> (raw)
In-Reply-To: <46A45A01.5050709@gmail.com>
On Mon, Jul 23, 2007 at 09:34:25AM +0200, Rene Herman wrote:
>
> The most profound issue is _what_ to save. I for example don't cylinder
> align my partitions (I hate wasting disk just to appease broken software)
> meaning that not all my end_head/sector values are consistent even at the
> best of times. Admittedly, I'm terminally analy retentive.
>
> Exactly. This is why I earlier said that really the only functional thing
> to do is not try to be smart and just grab things verbatim. This ofcourse
> does hinge on one's view of "good enough"...
Heh. Well, my definition of "good enough" is enough so that the C/H/S
fields are sane so that the BIOS can boot the system. So I don't care
about grabbing things verbatim since my higher priority is stuffing as
much data for as many partitions as possible into 512 bytes. Things
that require grabbing the C/H/S fields verbatim to avoid breakage I
would classify as "broken software". But, your mileage may vary. :-)
> That's not quite correct. Logicals have a start field relative to the
> encompassing extended (ie, for me always 1, for others often always 63) and
> the encompassing extended are relative not to the previous extended but to
> the level 0 extended (the one in the MBR).
This assumes that the extended partition is at the beginning of the
disk, yes? Why would anyone do that? I normally have /dev/hda1 at
the beginning of the disk, and I normally make /dev/hda4 my extended,
and place it *after* partitions at /dev/hda2, /dev/hda3, etc.
> So at most you get can 32-bit + 32-bit which could, yeah, in principle
> overflow into the 32nd bit -- it normally won't ofcourse since the start
> field, being relative, will be small, and I'd expect quite a few bits of
> software to break on this condition.
It would be interesting to see how badly modern Windows systems breaks
on this. If Windows 2000 and above works, and Linux works, then if
other things break it might be quite sufficient to consider them
"broken software" that we don't need to worry about.
> With 32-bit values (and 512-byte sectors) you can service 2TB -- anything
> above that requires something better than MS-DOS partition tables.
Well, in about 2-3 years or so we'll seeing having singleton disks
bigger 2TB. I'm not terribly sanguine about BIOS vendors and OS
providers migrating to something better by then, alas. Life is sure
going to be interesting. :-)
- Ted
next prev parent reply other threads:[~2007-07-23 13:48 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 5:13 [RFH] Partion table recovery Al Boldi
2007-07-20 5:20 ` Dave Young
2007-07-20 5:57 ` Dave Young
2007-07-20 11:29 ` [RFH] Partition " Al Boldi
2007-07-20 5:25 ` [RFH] Partion " James Lamanna
2007-07-20 7:00 ` Jan-Benedict Glaw
2007-07-20 11:29 ` [RFH] Partition " Al Boldi
2007-07-20 11:53 ` Anton Altaparmakov
2007-07-20 5:35 ` [RFH] Partion " Willy Tarreau
2007-07-20 5:44 ` Dave Young
2007-07-20 7:03 ` Jan Engelhardt
2007-07-20 11:29 ` [RFH] Partition " Al Boldi
2007-07-20 11:39 ` Jan-Benedict Glaw
2007-07-20 12:22 ` Al Boldi
2007-07-20 12:29 ` Rene Herman
2007-07-20 16:06 ` Theodore Tso
2007-07-21 17:54 ` Rene Herman
[not found] ` <20070722011141.GJ26752@thunk.org>
2007-07-22 4:10 ` Al Boldi
2007-07-22 16:28 ` Theodore Tso
2007-07-22 19:05 ` Al Boldi
2007-07-22 21:23 ` Indan Zupancic
2007-07-23 8:15 ` Rene Herman
2007-07-23 8:41 ` Jan-Benedict Glaw
2007-07-23 10:54 ` Rene Herman
2007-07-23 12:39 ` Rene Herman
2007-07-23 13:15 ` Jan-Benedict Glaw
2007-07-23 13:32 ` Rene Herman
2007-07-23 20:22 ` Bill Davidsen
2007-07-23 13:58 ` Theodore Tso
2007-07-24 4:08 ` Rene Herman
2007-07-22 9:11 ` Rene Herman
[not found] ` <20070722163934.GB20174@thunk.org>
[not found] ` <46A45A01.5050709@gmail.com>
2007-07-23 13:48 ` Theodore Tso [this message]
2007-07-24 3:41 ` Rene Herman
2007-07-20 6:47 ` [RFH] Partion " Jeffrey V. Merkey
2007-07-20 11:29 ` [RFH] Partition " Al Boldi
2007-07-20 7:35 ` [RFH] Partion " Anton Altaparmakov
2007-07-21 19:40 ` Willy Tarreau
2007-07-23 20:08 ` Bill Davidsen
2007-07-24 3:45 ` Rene Herman
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=20070723134835.GC19927@thunk.org \
--to=tytso@mit.edu \
--cc=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=rene.herman@gmail.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;
as well as URLs for NNTP newsgroup(s).