hi ya mike
On Tue, 27 Sep 2005, Mike McCarty wrote:
> >
> > the "tracking info" is dependant on the filesystem
>
> It is not.
i beg to differ ... different fs has different disk
structure to tune itself for various things to make
it better or worst than other fs
> It is used by the uController on the disc itself
> to servo.
the disk controller on the disk does its magic too
but that is 1 level lower than the track info needed
by the fs
the disk controller also does all the bad-block remapping
so that the fs thinks it has a clean 100GB of disks
even if its using 110GB of actual physical space
> A FS format should not disturb the low level
> format.
no it doesne't, but it uses that info in conjunction
with what it needs to be faster/better
> Anyone who redoes the low level format is taking
> his figurative life into his own hands.
those are the folks that insist on using "dd"
semi proof:
a) partition and format with xfs your test disk ( /dev/hdc )
with your favorite too
let's say test disk is all xfs and 8 partitions
b) use dd if=/dev/MasterDisk of=/dev/hdc
lets say MasterDisk is reiserfs
after the dd, you have lost all info about /dev/hdc
and the "test disk" is now a clone of MasterDisk
( the test disk is now 1 partition and reiserfs )
c) mark some blocks as bad with "badblock" command
and see what dd does to those sectors when you copy
one disk to another
> > some intermingle track info ( aka servo data ) with data
>
> Not without changing the ROM contained on the disc.
maybe there is a difference in what you call track info
and what i'm calling track info ..
servo data vs meta-data vs ??-data
servo data is on one platter as yu say,
OR interspersed amongst each track ( not on one platter )
meta-data is for the ext3, xfs, jfs, dos, etc
> I'm afraid that dd cannot see that information, nor
> can it destroy it.
sure it can ... try it ... the servo data is gone
that track-1234 head-6 sector-47 is not longer
marked as bad block because dd overwrote it
if the bad block is marked at the disk controller,
than yes, dd cannot change those badblocks and servo info
bad blocks is part of servo data ?? and is managed
in various wys
> >
> > fdformat or superformat ( low level formatting ) is done
> > separately from the filesystem formatting
>
> Yes, fdformat does the first two levels, but not the third.
yup
> > mkdos, format a:, mkfs.vfat, ...
>
> Which does the third level. (Though not the fourth.)
yup
> There is only one MBR per physical disc. Each partition has
> a BR, not an MBR.
okay ... i'll bite with the mbr vs br
> > not 100% sure but we all know any of these are bootable, each having
> > enough info to make it bootable
> > ( maybe a difference in terminology )
> > /dev/hda1 windoze
> > /dev/hda2 debian
> > /dev/hda3 redhat
> >
> > each partition has its own MBR allowing it to be bootable
>
> I'm afraid you have some misconceptions yourself.
just a difference of vocabulary of mbr or br per your correction
> > important to note that its active, but is NOT required to boot
>
> Depends on what boot program one is using. Since the current
> context is Windows, that is the context I used.
yup... i'm using lilo/grub context... nto sure if loadlin needs the
active boot flag
> > the boot sequence is configurable in the BIOS setting
>
> It may or may not be configurable in the ROM boot program
> settings.
sure it is ... always have been since 1979 ...
bootsequence:
floppy
cdrom
hda
hdc
usb-stick
network
- mix and match as you need and change it
- it is also stored in nvram or flash portion of the bios rom
- you know that once you change the boot sequence it
always uses that boot sequence .. and you do NTO have to
tell it again to boot from usb-stick or whatever you list first
> > 512 bytes
> > 2 bytes for boot flag
> > 64 4 partitons of 16 bytes each
> > ----
> > 446 is the actual mbr
>
> As I said, some consider the PT to be separate from the MBR,
> some consider it to be part of the MBR.
yup...
c ya
alvin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
