From: Mark Jarvis <mark.jarvis@xxxxxxxxxxxxxxxxxxx>
> HUH? FAT32 problem???
No, it's a geometry issue on legacy BIOS/DOS Disk Labels (Partition Table
Format) aka "Basic Disc" in NT5+ (2000+) when both NT and Linux share
the disk for booting.
Microsoft never standardized how geometry should be handled after NT4.0
Service Pack 4 (SP4) other than using legacy LBA32 -- i.e., always assuming
Sectors/Heads of 63/255. In NT5+, this is what it does on a "Basic Disc"
which cannot store geometry information, at least through NT5.1 (XP/2003)
Service Pak 1 (SP1).
Unfortunately, assuming LBA32 is not compatible with Extended Int13h
Disk Services. And for broken BIOSes, it can cause issues with 3rd party
boot managers and disk utilities. This isn't an issue with using the
Logical Disk Manager (LDM) Disk Label (Partition Table Format) aka
"Dynamic Disc" because all NT5+ (2000+) instances on the system can
read it's explicitly reserved areas and find out the exact geometry
assumed by the first NT5+ install that created it.
The Linux kernel as of early 2.4.x, thanx to work done by the NTFS-LDM
project, can also read this and not have to make any assumptions on
geometry (which can be an issue with 2.6 and its standard support for
Extended Int13h Services -- see below).
Microsoft has tried to address it with both some pre-NT5.1 Service Pack 2
(SP2) hot-fixes, some applied in SP2 and even more post-NT5.1SP2 hotfixes.
Because the legacy BIOS/DOS Disk Label does not have a place where to
reserve disk geometry, Microsoft choose part of Cylinder 0 where it's MBR
doesn't reside. Unfortunately, many 3rd party boot managers, including
GRUB, do use part of that space.
I've run into this first-hand where I had no problems dual-booting on even
a 800GB disk array _until_ I upgraded to NT5.1SP2 (XPSP2). After the
upgrade, GRUB was broken. After re-installing GRUB, it would no longer
boot XP, because GRUB overwrote the hidden geometry info in Cylinder 0
that XP needed for boot-time support. After a few more systems, I
discovered that XP only wrote it if the boot volume passed the 33.8GB
(32GiB) barrier -- at least on my disks that were BIOS LBA32 geometry
with Sectors/Heads of 63/255.
On newer disk arrays that break the 2.2TB (2TiB) barrier by supporting
LBA48 / >255 heads, you _must_ basically use a LDM Disk Label. It
appears Microsoft is not interested in any more "hacks" to support
legacy BIOS/DOS Disk Labels -- especially given the fact that a lot of
PC BIOS' out there are "broken" in their Extended Int13h Services
and support for geometry beyond LBA32. In a nutshell, Microsoft doesn't
trust anything from the PC BIOS, and expects to always rely on the
geometry info in the LDM Disk Label for now on (and I don't blame them).
Linux kernel 2.6 was written to the ATA-6/LBA48 and Extended Int13h
Services specifications to overcome the LBA32/2.2TB (2TiB) limit
but is breaking all sorts of things in the process. Newer user-space
tools like Parted and GRUB are now getting "more intelligent" in trying
to apply what geometry to "assume" based on what kernel 2.6 gives
them. It's no longer safe to blindly assume Sectors/Heads of 63/255,
which is how 2.4 and earlier used to deal with dual-booting.
> My system has two 120GB disks
I've typically found that as long as:
A) I'm not dual-booting late NT5.1 hot-fixes/service packs (i.e., SP2+)
B) I stay under LBA28/137GB (128GiB)
I don't have the issue, even when booting NT and Linux on the same disk.
> and a 160 GB disk.
As long as it is not the booting disk, and being shared by both NT
and Linux for booting, it shouldn't matter.
> The 120s have a 1GB DOS, a 24+GB NTFS, and a 84+GB FAT32 partition.
> I keep (almost) all of my data in the FAT32 partition.
Are you dual-booting Linux on the _same_ disk?
> The first 120 is (fairly) regularly cloned onto the second. Since I upgraded
> my BIOS, I have never had any trouble accessing anything in either of the
> big FAT32 partitions from either the XP installation or any one of the
> various Linux installations (CentOS, WBEL, SUSE, Fedora core 3, or Yoper)
> on the 160GB disk.
Then you're fine. As long as NT and Linux aren't sharing the same disk
for boot, you'll typically have no issues. The Linux kernel, even more so
2.6, is pretty good at trying to figure out the geometry. It's only when
booting that geometry can get screwed up, because you're at the mercy
of the BIOS -- or a boot-loader that attempts to overcome it's limitations.
On a LDM Disk Label (Dynamic Disc), it can directly read the geometry
assumed by NT.
On a legacy BIOS/DOS Disk Label (Basic Disc), it will try various geometries
-- from legacy LBA32 to (in 2.6) full standard Extended Int13h Services
geometry support. Unfortunately, NT5.1 doesn't support the latter (although
more hot-fixes are attempting to).
> At various times I have installed the NTFS code in a Linux installation,
> but when the NTFS crew's website says "read, but don't write" I believed
> them.
What I'm talking about is disk geometry issues. It doesn't matter if
NTFS or FAT32 is used, you can run into it when you dual-boot on the
same disc. Especially when you are dual-booting NT5.1 with late
hotfixes / service packs.
In fact, I highly recommend using the LDM Disk Label (Dynamic Disc)
on any NT5+ accessed disk to avoid geometry issues between NT5+
itself. Otherwise, I've seen people dual-booting 2000 and XP and
seen the Disk Label (Partition Table) get trashed.
--
Bryan J. Smith mailto:b.j.smith@xxxxxxxx
