[NTLUG:Discuss] Re: recuse the data -- absolute or relative track 0?
Bryan J. Smith
b.j.smith at ieee.org
Wed Nov 10 11:38:49 CST 2004
On Wed, 2004-11-10 at 10:54, Gilbert Morrow wrote:
> According to my A+ cert manual track 0 is where FAT resides that is
> the outer most track of the first sector on the hard disc , so it may
> be that FAT is corrupted .
The question then becomes ...
- Is is the _absolute_ track 0 of the hard drive?
- Or the _relative_ track 0 in a filesystem?
If the system will not boot after the Power-On Self Test (POST), and
track 0 cannot be read, then it is the _absolute_. The code at 20-bit
address (Real86 mode) FFFF0h in the BIOS tries to jump to the first
_absolute_ 512 byte sector of the hard drive also known as the "master
boot record."
Under Linux, this would be a device like /dev/sda, /dev/hda, etc...
If the system will not mount a specific filesystem, such as with a
mount, or after the master boot record (MBR) loads and tries to attempt
to jump to the first _relative_ 512 byte sector of the _filesytem_, also
known as the "bootstrap," then it's the _relative_ track 0 of a specific
filesystem.
Under Linux, assuming the legacy DOS disk label (partition table) of
primary-logic slices (partitions) aka a "basic disk," this would be a
device of /dev/sda1, /dev/hda1, etc... noting the "1".
As far as the FAT, it depends. If it is FAT12/16/32, it is typically
stored after the first, relative 512 byte sector for the bootstrap --
possibly after the [IBMB]IO.SYS file (at least before MS/PC-DOS 5.0).
On NTFS, the FAT is stored in the middle of the disk.
The FAT may start in relative track 0 -- and typically does on MS/PC-DOS
5.0 and later, including MS-DOS 7.0/7.1 (aka Windows 95/98/ME).
> The info saved there is what Windows used for the boot process and I
> guess Linux uses the same space ? don't know about that thought.
Again, typically the FAT typically starts just after the first, relative
512 byte sector of the filesystem for the "bootstrap."
> It is located there so that the read /write head does not have to move
> so much to access the data. And also that way the process never needs
> to change.
Actually, in NTFS, the FAT is relocated to the middle of the filesystem
for that very reason. The idea is that the head only has to, at most,
seek half as far from the FAT to the data, regardless of the location of
the data, versus the FAT12/16/32 filesystem approach of the beginning.
These concepts, of course, apply to FAT filesystems and not to inode
(superblock, direct/indirect pointer) filesystem designs.
--
Bryan J. Smith b.j.smith at ieee.org
------------------------------------------------------------------
"Communities don't have rights. Only individuals in the community
have rights. ... That idea of community rights is firmly rooted
in the 'Communist Manifesto.'" -- Michael Badnarik
More information about the Discuss
mailing list