Gecko/20101207 Thunderbird/3.1.7
UTC)
comp.os.os2.misc:2903 comp.os.linux.setup:7764
From: Jonathan de Boyne Pollard
>> 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)
|
