Text 2778, 111 rader
Skriven 2011-02-14 04:12:50 av Jonathan de Boyne Pollard
Ärende: Re: Ubuntu installation modifies the partition table rendering IBM LVM 
===============================================================================
Gecko/20101207 Thunderbird/3.1.7
UTC)
comp.os.os2.misc:2903 comp.os.linux.setup:7764
From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>

>> 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.
>>
> Maybe it is, but there is demonstrably an existing base of legacy 
> software that rigidly assumes it. (OS/2 has always been notoriously 
> strict about this, or at any rate since the Warp 3 days at least.)
>

Actually no.  And that's the point.  There's an existing base of 
software.  (What was the point of the word "legacy" in that sentence?  
"Legacy" doesn't mean what you think it to mean.)  But it's software 
that *enforces* the restriction, rather than that *assumes* it.  IBM's 
FDISK, for example, enforces various restrictions, purportedly for the 
benefit of other operating systems.  But in fact those other operating 
systems do *not* assume the restrictions being enforced.  FDISK enforces 
cylinder alignment.  But I cannot recall off the top of my head *any* 
operating system back as far as DR-DOS 6 that actually *requires* this 
in order to work.

FDISK has several wholly unnecessary impositions, and this is one.

> According to Jan van Wijk, the relevant standards don't clearly define 
> what the correct behaviour in this case is, hence the trouble that 
> people have getting different OSes to cooperate (as each OS may well 
> take a different interpretation of what constitutes acceptable behaviour).
>

You're mixing up two different things.  The thing that M. van Wijk has 
commented upon is the CHS geometry mapping, what algorithm is used to 
transform a logical block number into a CHS triple.  That's not the 
concept at hand in the present discussion.  What we're talking about is 
the idea, commonly stated, that no partition begin anywhere other than 
sector #1 of a track, according to the logical geometry visible at the 
INT 13h interface.  *That* idea is a nonsense.  Aside from the fact that 
most existing operating systems don't even use the CHS information in 
the partition table, the whole underpinnings of the idea is flawed.  
What are visible as "tracks" at the INT 13h interface do not necessarily 
bear *any* relation at all to the actual tracks on the disc.  That 
notion went away in the 1990s with translated CHS geometries.  (ATA 
discs have had zoned bit recording for years, now, too.  There's not 
even a fixed track size across the platter.  So even the *logical*, 
untranslated, geometry bears no relation to the physical one.)

This knocks out the foundation of the whole idea.  The *reason* that one 
track-aligns is to have fine-grained control of sector placement, so one 
can allocate sectors so that they pass under the read/write heads with 
known patterns.  Back in the 1980s, operating systems were big on this, 
and one heard talk of track-to-track sector skewing and suchlike.  But 
with a SCSI or an ATA disc it's just a nonsense.  Neither the translated 
geometry, visible at the INT13h interface and what the partition table 
entries use in their CHS fields, nor the logical geometry, presented at 
the ATA device register level, are the actual, physical, geometry of the 
disc.  If one isn't aligning to the actual physical track/sector layout, 
but for some entirely fictional geometry that only exists at the level 
of a firmware API at two removes from the physical geometry, then all of 
one's optimization to make sure that the right sector is ready under the 
heads after a seek is a nonsense.

> Personally -- not knowing much about low-level disk layout but from a 
> more generic perspective as a software engineer -- OS/2 may be guilty 
> of overly pedantic behaviour, but Ubuntu is also being grossly 
> presumptuous.
>

I maintain that what Ubuntu is doing in this instance is fine, and in 
fact a good thing.  It's nigh on time that this nonsense folkloric idea 
-- which appears to have developed more as a result of Chinese Whispers 
and guesswork than from any formal specification -- was given the 
elbow.  It's been twenty years.  No operating system *itself* since at 
least the days of DR-DOS 6 has actually had a problem with 
non-track-aligned volumes to my knowledge.  Enough's enough.

It's what IBM's LVM is doing that isn't fine.  It's making unwarranted 
assumptions about where it can just grab an unallocated disc block 
without explicitly allocating it.  As I noted, other disc management 
systems *do not do things this way*.  Microsoft's Logical Disk Manager 
uses a special partition, whose type is "LDM Metadata" (EFI partition 
type 5808c8aa-7e8f-42e0-85d2-e1e90434cfb3), and puts the metadata 
there.  The Linux LVM (we are told) stores the metadata within each 
partition.  There's a reason that the rest of the world doesn't do 
things the IBM LVM way, and hasn't done for at least a decade now (There 
is Windows 2000 Server doco that talks about the pitfalls of expecting 
unallocated areas of the partition table to be usable.), and this 
experience *is* that reason.  It's a flawed and selfish design and 
doesn't work.

The most telling point here is that in the Microsoft world at any rate, 
this fabled and folkloric track alignment by partitioning utilities went 
away some years ago, to much fanfare.  Microsoft's partitioning 
utilities now by default align (MBR) partitions to multiples of 1MiB 
instead of to multiples of the INT 13h track size.  The argument for 
changing is a simple one.  Aside from the fact that aligning to INT 13h 
tracks is entirely meaningless from the point of view of the physical 
layout on the disk platter, it causes secondary partitions (and some 
primary partitions) to begin on odd-numbered logical block numbers.  
Aligning to 1MiB gives partition beginnings even-numbered logical block 
numbers (and, moreover, whole number multiples of multiple-block 
*cluster* sizes, such as 4KiB, as well).

In other words: The kilo-Newton Gorilla has already said "Enough's 
enough!" some years ago.

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