Text 2767, 97 rader
Skriven 2011-02-12 10:37:15 av rusi
Ärende: Re: advice on hardware purchase
=======================================
798279ab
GMT)
posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui
comp.os.os2.setup.storage:366 comp.os.os2.misc:2892
From: rusi <rustompmody@gmail.com>

On Feb 12, 7:48 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...@NTLWorld.COM> wrote:
> >>> This may be related:http://bugs.ecomstation.nl/view.php?id=2914
>
> >> Seems that I can't view the bug without an eCS userid.
>
> > You don't have one? Well, most of the same info is available in the
> > same user's Ubuntu bug report:
> >https://bugs.launchpad.net/ubuntu/+bug/669459
>
> > He also observes that it writes into the Windows partition as well...
>
> I've identified two things being adjusted.
>
> The secondary MBR in relative block #0 of an extended partition is being
> modified.  The modifications are essentially twofold.  The IBM
> extensions to the partition table, containing the 8-character partition
> name and "bootable" flag, are being zeroed out wholesale.  And the start
> block numbers of the contained partition entries are being reduced by 61
> (0x3D), reducing the first, for example, from 63 to 2.  The added
> information in block #1 that we can see from the diff is actually the
> LVM information, moved from block #62 of the container to block #1.
>
> The primary MBR in absolute block #0 is being modified.  The
> modifications are to the fourth entry in the partition table.  Its start
> position is being increased by 0x3D and its length is being decreased by
> 0x3D.  It's a fairly easy deduction that the fourth entry is the
> extended (type 0x0F) container partition.
>
> So what's essentially happening here is that something in Ubuntu's
> installation procedure is reclaiming unused free space by resizing a
> type 0x0F container, squeezing the secondary MBR right up against the
> LVM information instead of leaving some 62 unallocated blocks in
> between. This is actually a good thing.  The idea that partitions have
> to be track aligned to the geometry used at the INT 13h interface,
> whence this track's-worth of wasted space comes from, has been a
> nonsense for almost two decades at this point.  Ubuntu's partitioning
> utility is allowing the space that the bogus alignment wastes to be
> potentially reclaimed.  Here are the holes comprising the wasted space
> caused by this nonsense on one of my hard discs:
>
>
>
> >  [C:\]dasdpart /c free /efi- 0
> >  There are 12 areas of free space on the disc.
>
> >                  5           62           58   29.0KiB
> >              32131        32192           62   31.0KiB
> >            4225096      4225157           62   31.0KiB
> >           12627091     12627152           62   31.0KiB
> >           21013021     21013082           62   31.0KiB
> >           37800946     37801007           62   31.0KiB
> >           54588871     54588932           62   31.0KiB
> >           71376796     71376857           62   31.0KiB
> >           88164721     88164782           62   31.0KiB
> >          104952646    104952707           62   31.0KiB
> >          121740571    121740632           62   31.0KiB
> >          138528495    321669494    183141000   87.3GiB
>
> (Yes, M. Hemsley, if you are reading:  That's the DASDPART that I just
> pointed you to.)
>
> The true culprit is really LVM.  It cannot find its metadata in block
> #62 any longer, because, although it is at the same physical location on
> the disc the container partition has been repositioned around it,
> renumbering the relative blocks within the containers.  So block #62 is
> now numbered block #1.  Clearly LVM doesn't look there.  (What the exact
> algorithm it uses for locating its metadata is unknown.  I've seen
> various educated guesses over the years, including "last sector on the
> same track as the secondary MBR", which is probably really, in the code,
> "add Geometry.SectorsPerTrack-1 to the block number", which is not
> quite, in the modern age of non-aligned partitions, the same thing.  It
> could also be "the block before the first block of the contained
> secondary partition", but the fact that LVM is going wrong here when the
> actual positions of the partitions and the positions and content of the
> LVM data structure on disc have not changed, seems to rule that out.)  
> It's as I said before: IBM's LVM didn't follow in the wise footsteps of
> IBM's BootManager (and various other people's dynamic disc management
> data structures, including Microsoft's) and the chickens have now come
> home to roost.  The wasted space is no longer present, there's no
> unallocated 62 blocks to play with, and the idea that one can just go
> ahead and use that space assuming a (non-existent) guarantee that it
> will always be a specific number of sectors, breaks.


I asked a similar/related question on the grub list
Maybe some of the answers help?
http://lists.gnu.org/archive/html/help-grub/2011-01/msg00017.html

--- Internet Rex 2.31
 * Origin: http://groups.google.com (1:261/20.999)