Welcome, Guest. Please Login
 
  HomeHelpSearchLogin FAQ Radified Ghost.Classic Ghost.New Bootable CD Blog  
 
Pages: 1 ... 5 6 7 
Send Topic Print
Disappearing partitions in Ghost 2003 (Read 94375 times)
Dan Goodell
Special Guest
*****
Offline



Posts: 552
N California


Back to top
Re: Disappearing partitions in Ghost 2003
Reply #90 - Dec 14th, 2010 at 1:14am
 
NightOwl wrote:
    So, my general take away message for modern HDDs is: CHS and HDDs is a series of *smoke and mirrors*--the whole thing is *make believe*--and has no real basis in reality--everything is simply *pretend* and as long as everyone agrees--everything is *ok*!

YES!  Now you're catching on!   Wink

As much as I despise Microsoft's arrogant, "go-it-alone" attitude in their invention of their new, MB-aligned partitions, at least they're finally giving up the charade of cylinders and fictitious geometry.  "The Emperor has no clothes!"



In reference to:
    who's in charge here...?

NightOwl wrote:
    There is the BIOS, the HDD controller on the motherboard, and the controller *inside* the HDD (is there anything else I'm missing?)

There is no such thing as a HDD controller on the motherboard anymore.  It's merely an interface connection.

Back in the MFM/RLL days, you needed a controller on the motherboard or an add-in card, and that controller directly accessed the "dumb" disk drive by directly addressing the cylinder, head, and sector the controller wanted to access.  Drive manufacturers provided their products with a certain number of physical platter sides (aka, heads), tracks per platter (aka, cylinders), and sectors per track.  The controller needed to know what those values were in order to know what it had access to.

With the advent of IDE drives ("Integrated Drive Electronics"), the controller was moved from the motherboard or add-in card and physically attached to the hard drive itself.  That move opened up all sorts of flexibility for the drive manufacturers.  Since they now had control over the HDD controller, they could customize its firmware to report back to the motherboard and bios whatever numbers they wanted without having to reveal the true number of physical platters, tracks, and sectors/track they were using.

The bios and operating systems could only accept particular ranges of values, so drive manufacturers could have their IDE controllers report back values in the acceptable ranges while behind the scenes there were actually fewer platters, more tracks per platter, and more sectors/track.  They could even use tracks with variable numbers of sectors, packing more sectors in the longer tracks near the outer edges of the platters.  All of this mapping between the actual sectors and what was reported to the outside world was now strictly under the drive manufacturer's control.  (Some manufacturers post detailed data sheets on their websites.  Today, mainstream HDDs usually have only 2 or 3 real platters.)

Another side-benefit is that manufacturers could now work around the inevitable defective areas of the platter surfaces.  They could now map just the good sectors to the outside world--which is why today's drives appear to be perfect, with no bad sectors.  In truth, every platter has bad sectors, but the controller maps them out of service.  If there are more than enough good sectors, the spare sectors are held in reserve.  This small cache is what the controller's S.M.A.R.T. monitor can use to "replace" sectors that are starting to go bad in the user-accessible area.  In actuality, a sector can't be replaced, but a bad sector is mapped out of service and one of the reserves is mapped in in its place.



In reference to:
    Note this idiosyncracy is dependent on the bios, not the HDD itself. Any autodetected HDD will always show 240 heads in a Thinkpad, and always show 255 heads in a Dell. Since all that really matters is the disk size, you'll notice the cylinder count is adjusted to provide the same disk sizes under either bios.

NightOwl wrote:
    Well, that says the BIOS is *in charge*--right?!

Modern BIOS firmware "autodetects" the HDD parameters, so in that sense the BIOS is in charge.  At startup, the BIOS POST routine sends an ATAPI "IDENTIFY" query to the HDD's on-board controller.  What the BIOS does with that information is up to the BIOS.

For example, a 500GB disk drive might respond to an "IDENTIFY" query by reporting that it has 500,006,545,920 sectors and a "geometry" of CHS=16383/16/63.  (Note: most of today's HDDs larger than 137GB respond back with this geometry--I imagine for backward compatibility with older BIOS firmware.)  BTW, this is the geometry you will sometimes see printed on the HDD's label, even though the HDD size is larger.

The BIOS autodetect routine takes the LBA number and does its own math, using preset values of 63 sectors/track and either 240 or 255 tracks per cylinder.  IOW, it might calculate CHS=60789/255/63 or CHS=64588/240/63 for this 500GB example.  Some BIOS's might display this result in their BIOS Setup pages.

Remember, the geometry the controller reports to the BIOS is fictitious, and the geometry the BIOS autodetects is a different fictitious set of numbers.



 
 
IP Logged
 

Dan Goodell
Special Guest
*****
Offline



Posts: 552
N California


Back to top
Re: Disappearing partitions in Ghost 2003
Reply #91 - Dec 14th, 2010 at 1:14am
 
NightOwl wrote:
    So the BIOS *tells* the partitioning software that the HDD attached to it will be either a 240 head HDD, or a 255 head HDD. And, the HDD from that point on *remembers* that 240 or 255 head * fake geometry*
    . . .

No, the HDD doesn't know or care what geometry everybody else is using.  If anybody asks, it claims to be 16383/16/63.

Utilities might get the HDD parameters either by asking the BIOS what it autodetected, or by directly asking the HDD's controller.  For the sake of consistency amongst operating systems, I believe most partitioning programs ask the BIOS for the numbers.  Since the function calls do not have room for large cylinder values, the BIOS responds to the program with either 1023 or 1022 (perhaps for the historical reasons previously mentioned).  Now you have a third set of fictitious numbers.


    . . .
    and it can not be placed on a different machine which uses a different head count than was initially used and be accessed--it has to be on a machine whose BIOS reports the same head count as was originally used to format and partition the HDD.

No, the HDD can be placed in any system.  What matters is whether the operating system in use can find the data it's expecting in the places it's looking.

Programs that rely on CHS access (such as DOS 7.0 and earlier) do indeed need to see a consistent geometry.  But CHS is irrelevant if an OS is looking for data via LBA.  Linux and Windows (once it's finished booting) use LBA.  They have no trouble accessing data sectors, regardless of the fake geometry being used, because LBA access ignores geometry.

The problem is the initial phase of the Windows boot process uses CHS, so it can have trouble finding the files it needs to boot itself far enough before it switches over to LBA.

As Brian reported in Reply #88, "Data partitions still worked but when done on the OS partition it no longer booted."



In reference to:
    The early part of this thread was about the numbers actually recorded in the partition table. The latest posts are about the BIOS and geometry autodetection. Those are two different topics.

NightOwl wrote:
    I'm not sure what you mean here--seems like everyone is posting their *PartInfo* summaries--isn't that the *actual numbers recorded in their partition tables*?

Yes, actual numbers ... which don't subsequently change just because somebody's fake geometry calculations might change.

The early part of the thread was about the numbers in the partition descriptors, which may have been derived from the geometry at the time they were written, but thereafter are just numbers.

The later part of the thread started getting into geometry *changes*, which has no effect on numbers already written to a partition descriptor on the hard drive.



    So, Brian posted his BING PartInfo's, and he simply changed in BING how he wanted the CHS to be reported ..."

No, not "how he wanted CHS to be reported."  The BIOS is going to report CHS as per the code embedded in its firmware.  BING can't change that.  Brian was merely directing BING to write a partition table with different numbers than BING is getting from the BIOS.  That doesn't mean the HDD will adopt that geometry, only that that geometry will be used to calculate what to put in the partition table descriptors.

Remember, the geometry written into the partition table descriptors doesn't necesssarily have to agree with what the BIOS autodetects.  Normally, you want it to agree or the OS might not boot, but you can put anything in the partition table descriptors.  In fact, that's what Brian is exploring in Reply #88.  The descriptors are just bytes in a data sector on the hard drive.  Like any data sector, the bytes don't change unless some program specifically rewrites the sector.

(Aside: the only thing special about the MBR sector is it happens to be the first sector.  Other than that, it is just another data sector.  Its bytes may represent some special meaning, but they are ordinary bytes in an ordinary sector.)


 
 
IP Logged
 
Dan Goodell
Special Guest
*****
Offline



Posts: 552
N California


Back to top
Re: Disappearing partitions in Ghost 2003
Reply #92 - Dec 14th, 2010 at 1:14am
 
In reference to:
    After running a whole-disk image/restore from Windows with Ghost 2003, the "after" PartInfo exhibited several of the 1022-vs-1023 anomalies and rollover anomalies, as described in my Reply #55

NightOwl wrote:
    You mean you used the Ghost 2003's Windows interface to set up the Ghost restore *disk from image* procedure which then did the boot to DOS to proceed, and then back to Windows--correct?!

Yes.  Any partitioning or cloning program must necessarily rewrite the partition table as a byproduct of the cloning or repartitioning operation.  The experiment was to see if perhaps Ghost was recalculating the descriptors incorrectly before it rewrote the partition table.  It turns out it does.  Since I haven't noticed such errors when using Ghost 2003 from DOS, the experiment implies the problem is in whatever makes Ghost 2003 from Windows different from Ghost 2003 from DOS.



Additional comments, FWIW:

As mentioned above, programs typically get geometry parameters from what the BIOS calculates at boot time, but a program could directy query the HDD if it wants.  It appears to me the CHS and WCHS geometry numbers PartInfo shows are probably coming from two different places--one from a call to the BIOS and one calculated from a call to the HDD's controller.

In a similar vein, my Dsrfix program queries both sources.  The ATAPI function call to the HDD controller is different if the HDD is larger than 137GB.  If the BIOS is not 48-bit LBA aware, it will use the wrong ATAPI call and cannot access the part of a HDD beyond the 137GB boundary.  In layman's terms, Dsrfix directly asks the HDD, "How big are you?"  Then it asks the BIOS, "How big do you think the HDD is?"  If those figures are different, that verifies the BIOS has a 137GB limit.

Discussion of the 137GB limit is off-topic in this thread, but I present it as an example of how a program can get different responses depending on who it asks.  (Aside: Dsrfix can be run on any machine, though its purpose is to evaluate Dell XP machines with the Dell System Restore feature.)


Sample Dsrfix report illustrating the BIOS limitation:

    DSRFIX - Dell DSR Analyzer, version 3.12
    Copyright 2005-2008 by Dan Goodell, all rights reserved.
    (Type DSRFIX /H for syntax help)

    Disk 80 found, master device at port 01F0
    48-bit user secs  : 312581808 (160 GB)
    48-bit max secs   : 312581808 (160 GB)
    i13/48 user secs  : 268435455 (137 GB)
    disk cyls/hds/secs: 16709/255/63

    alert: boot code does not match dell mbr.
    good : pbr descriptor 1 is type DE.
    good : pbr descriptor 2 is type 07.
    good : pbr descriptor 3 is type DB.
    info : pbr descriptor 4 is type 00.
    good : pbr1 is fat16, label is DellUtility.
    fatal: pbr3 is not fat32.
    alert: reference partition table not in sync.


    disk model number : WDC WD1600BEVE-00WZT0                  
    48-bit feature set: supported
    hpa feature set   : supported





 
 
IP Logged
 
Pages: 1 ... 5 6 7 
Send Topic Print