When 16 = 240 and Disk Labels v. Filesystems -- WAS: fc2 issues

["Bryan J. Smith" <b.j.smith@ieee.org>]

Robert G. (Doc) Savage wrote:  
> Bryan,
> Couple of nits...

First off, to -- Summarize --    

1.  The "240 heads" is a 5-bit v. 8-bit compatibility issue.  "16 heads" in 5-bit
may be read as "240 heads" in 8-bit (because there are 3 "ones" that come from
"somewhere" -- yep, the "63 heads" 'next door' ;-). (read on)

2.  Don't confuse the LDM "disk label" (partition table) with the NTFS
"filesystem."  NTFS v6 (Longhorn) and NTFS v7 (Blackcomb) _still_ use
the LDM disk label.  And it looks like support for the old DOS disk label 
_may_ be dropped in 2006+. (read on)

-- Point of no return from technobabble (I hope Doc enjoys ;-) --

> Not all Thinkpads use a 240/63 heads/sector translation. fdisk reports
> c/h/s geometries of 93015/16/63 and 9729/255/63 for my 48G and 80G IBM
> notebook drives, respecively. Neither of these drives has ever been
> touched by That Other OS(tm), except in VMware virtual machines.

What the disk reports, and what the various Int13h Standard/Extended disk
services report are _often_ different.  Why?

Well, most disks still ship with 16/63, because many pre-1997 (and even
some pre-2000) BIOSes do not support more than 16 heads.  So that's where
the common 255/63 translation comes in.  So the BIOS provides it.

Unfortunately, some buggy BIOSes get confused.  Or, worse yet, the _fail_
to provide the full ATA-BIOS spec for Extended Int13h services.  So
where does the 240 come from?

16 decimal in 5-bit is 10000 binary
16 decimal in 8-bit is 00010000 binary

If you have a legacy BIOS only providing 5-bits, then those top 3-bits 
must come from elsewhere.

In typical, little endian storage, the number of sectors in cylinder/heads
/sectors (CHS) is going to be stored _before_ (or after, depending on which
way you look at it -- hardware or software ;-) the number of heads.  So
those top 3-bits will now come from sectors.

And what are the number of sectors used?  63

63 in 6-bit is 111111 (all ones)

So let's add 3-bits of ones (111) to the front of our 5-bit bits for 16 (10000).
11110000 binary = 240 decimal

That's where it comes from.

If the Extended Int13h services does _not_ provide the proper 8-bit number
of heads, and only provides the 5-bits, then you're going to get 240, because
the last three bits are ones, which are part of the number of sectors.

I remember dealing with this same issue back in the late '90s and doing
all sorts of memory dumps of various BIOSes to look how such things were
stored.

> With Longhorn and its reported radically new filesystem just two
> years away (well, some small number anyway), I think your prediction
> about Microsoft's LDM may be wishful thinking.

Okay, let's step back. (sorry to be simple here, but ...)

Remember when they told you in DOS that you needed to "partition first" with
"fdisk" and then "format" with "format"?  That's because you needed to first
apply a "disk label" (partition table) and _then_ "format" the filesystem.

So, when does the "disk label" have _anything_ to do with the "filesystem"?

Microsoft, as of NT 5.x (2000, XP, 2003), supports 2 "disk labels":
  Pre-NT 5.x:  "basic disk" aka "MBR disk" aka "DOS disk" label
  NT 5.x+:  "dynamic disk" aka "LDM disk" label

You can have FAT16, FAT32 and NTFS v4 and NTFS v5 filesystems under _both_
types of disk labels.  The type of disk label selected does _not_ impact
what you can have.

The "basic disk" has primary and logical (in extended) partitions.
The "dynamic disk" has simple, spanned, mirrored, etc... volumes.

What filesystem goes into those volumes is not a consequence.  The LDM specs
have been reverse engineered.  The Linux-LDM kernel driver allows Ext3 
and other filesystems to be created and mounted in at least LDM "simple"
volumes.  LILO is a "dumb" sector-offset boot loader that can then load
then at boot.

So all we are missing are the following:  
A.  A GRUB that understands LDM (so it can boot)
B.  User-space utilities for Linux that allow "simple" volumes to be created
   in a LDM disk label.

In fact, I wouldn't be surprised if Microsoft starts _removing_ the option
to use the legacy "basic disk" in NT 6.0 ("Longhorn").  That's why supporting
the "dynamic disk" aka "LDM disk label" is _essential_ for _future_ dual-
booting with NT 5.x+ IMHO.  Don't be surprised when all you can create is a
"dynamic disk" in a new install of "Windows 2006 Home/Prof" and you _must_
"upgrade" your "basic disk" to a "dynamic disk" in "Windows 2006 Home/Prof
Upgrade."  Yes, the Primary and Logical (Extended) approach will be no more.

The LDM disk label was created by Microsoft for at least four reasons:  
1.  To store actual, raw disk geometry and any translation for all entries
2.  To provide references for complex volumes (RAID, etc...)
3.  To offer basic transactions/journaling during volume creation/modification
4.  To offer hidden storage areas for storing of Registry-SID info

#1 is a major benefit for Linux when dual-booting because we can now read
what NT 5.x things the disk geometry is _exactly_, instead of "trying to guess"
like we have in the past by reading the legacy DOS disk label.

#2 and #3 are probably just benefits for NT 5.x+ and redundant to what we have
with LVM/LVM2, so there is no need for Linux to take advantage of them.  Unless,
of course, LVM2 wants to use the same from the disk label standpoint.  But AFAIAC,
just using "simple" volumes for LVM, Ext3, etc... works fine.

#4 is a biggie that is _not_ well known.  You see, even different versions of NT
can_not_ safely write to a NTFS filesystem _unless_ that is the version of NT
that created the NTFS filesytem (this isn't just a Linux thing).  Why?  Because
SID and other NTFS objects are stored in the registry, and only the system that
created the NTFS volume has these.  LDM offers a hidden area to store these
references for a NTFS volume, so any other NT 5.x+ system can read them and
safely write to that NTFS volume.

LDM will _continue_ to be _the_ disk label of choice by Microsoft.  It is designed
to be the disk label for _all_ future versions of NT.  It is _required_ for IA-64,
even though Intel has its own General Partition Table (GPT) design.  For NT to
work on Itanium, you must create a LDM disk label inside the GPT disk label.
The LDM disk label is the common requirement, no matter what the platform.

Again, don't be surprised when you can't see anything but "partition type 42h"
in legacy partitioning programs after installing or upgrading to "Windows 2006
Whatever."  (LDM shows a single primary partition type of 42h for read
compatibility with older bootloaders/partitiong programs).

> The way I hear it (rumors at best), NTFS may not be supported in Longhorn.

First off, that wouldn't affect LDM at all.  NTFS v6 is just another filesystem
under LDM.

NT 6.0 is shipping with NTFS v6, which is basically NTFS v5 with an embedded
SQL Server.  Any plans to radically change the structure of NTFS have been
shelved to meet an early 2006 release date for NT 6.0 client, and an early 2007
release date for NT 6.0 server.  All "promised Longhorn technologies" are now
being pushed back to NT 7.0 "Blackcomb."  This is a recent admission/omission
(same thing ;-) by Microsoft, confirmed by several sources (e.g., Ziff-Davis'
Microsoft Watch).

There is no reason to assume NT 7.0 "Blackcomb" would not use LDM either.  LDM
will handle all disk label needs for a decade or more, just like the legacy
DOS disk label of primary/logical(extended) did before that.  But unlike the
legacy DOS primary/logical approach, LDM can store all that hidden meta-data
that can't be in the filesystem.  It's designed to be extensible in this regard.

<tangent>
Microsoft is also pulling plans to use .NET as the ABI/API of the system
software, and is sticking with Win32/Win64.  .NET will be limited to Internet/
Web services, which offers a "sandbox" (for Internet services) atop of Win32/64
(which is what the OS still runs).  The "hack" on the desktop is to re-introduce
the concept of the "ActiveDesktop," where MS IE controls all user interaction.
That way you can still have the Win32/64 platform, but the user experiences
.NET -- ala via web services, but it is transparent to them.

This is also how Microsoft is accomplishing an experience similar to "Quartz
Extreme" on MacOS X and the developing "Cairo" from FreeDesktop (which is used
by Mono.NET and, assumingly, Gnome 3).  They are redesigning the GDI+ framework
Win32/64 to handle multiple multimedia streams from .NET web access.  I could
discuss this at lenth, as well as what else is _not_ shipping in NT 6.0.

Sounds like old "NT 4.0 Cairo" all over again, eh?  ;-ppp
"Push it back to NT 5.0^H^H^H7.0, eh?"  ;-ppp
</tangent>

> I'm sure they'll offer conversion utilities (a la FAT > NTFS), but that's
> about it. This could be a major concern to those who need to retrieve data
> from archival tape backups of NTFS 4/5 filesystems.

???  I fail to see any relevance here.

LDM is not tied to NTFS v5 anymore than FAT32 is or NTFS v6 would be.  LDM
is designed to do #1-4 above, and that includes storing any off-filesystem
meta-data necessary to support NTFS v5, as well as the forthcoming NTFS v6,
NTFS v7 and on-ward.

It's just a disk label dude.  Nothing more.  ;->

Disk labels have 0 to do with the filesystems contained in them.  They
might offer features (and LDM does over the legacy DOS disk label), but
there is no reason for LDM to ever change in design.  It's extensible.

-- End of technobabble --

> BTW, you must have had a momentary case of happy fingers when you typed
> "fruitition". That one stumps me. Did you really mean to say
> "frustration"? (I'm sitting here chuckling as the irony sets in.)

Just call me the mega-typo man.
Now I did mean to say a "lesson in fruition."
That's all.


-- 
Bryan J. Smith, E.I. -- b.j.smith@ieee.org



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.