Text 2761, 105 rader
Skriven 2011-02-12 14:48:06 av Jonathan de Boyne Pollard
Ärende: Re: advice on hardware purchase
=======================================
Gecko/20101207 Thunderbird/3.1.7
comp.os.linux.misc,comp.os.os2.ecomstation,comp.os.os2.misc,comp.os.os2.setup.storage,comp.os.linux.setup

UTC)
comp.os.os2.ecomstation:852 comp.os.os2.misc:2886 comp.os.os2.setup.storage:364
comp.os.linux.setup:7755
From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>

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

What's happening in the type 0x07 partitions is unknown.  The block 
numbers supplied by M. Kluge are large and essentially meaningless.  For 
all we know, that could be something benign, such as updating the last 
accessed timestamp on the root directory MFT entry of an NTFS volume or 
updating the last CHKDSK timestamp in the superblock of an HPFS volume.  
Whatever it is, it is unrelated to the LVM problem, and possibly is a 
side-effect of something completely different in the installation 
process (such as the installation utility automatically mounting all 
available disc volumes, for example).

You'll probably want to direct M. Kluge to this diagnosis.

--- Internet Rex 2.31
 * Origin: virginmedia.com (1:261/20.999)