To be able to get Ghost 2003 working with Windows 7, one of the things to remember when installing Windows 7 is to pre-partition and pre-format the drive from within e.g. Windows XP to get the partitions aligned correctly.

Now, the new drives have 4 kB sectors with 512-byte emulation. I have read the Advanced Format Technology Brief from Hitachi but am not sure that I understand.

On page 3, they distinguish "Advanced Format Aware Operating Systems" from "Legacy Operating Systems". As I understand it, this difference is what we have utilized when pre-partitioning and pre-formating. To be able to use the new drives, this can not be done and in concequence, Ghost 2003 is "out".

Am I right?

@ Christer

Just some brief comments as I'm interested to hear what Dan has to say about this situation.

First, you can't create 2048 sector aligned partitions with WinXP so when you create your partitions prior to installing Win7, use a 2048 sector aware tool. You can use Diskpart from a Win7 DVD. I use BIBM.

This web page has interesting information...

http://www.terabyteunlimited.com/kb/article.php?id=546

Using Diskpart....

boot from a Win7 disk
at the Install Windows screen, press SHIFT F10 to get a Command prompt

type diskpart and press Enter
list disk
select disk 0 (use the number relevant to your HD)
list disk (there will be an * next to your selected disk)
clean (use this if you want to delete all partitions on the selected HD)
create partition primary size=80000 (use whatever size in MiB you desire)
select partition 1
active
format fs=ntfs quick 
assign
exit
exit

You are now ready to install Win7 into this partition. You can create other partitions (using Disk Management) after Win7 is installed.

Brian,
now I'm totally confused.

There must be some reason why I have partitioned and formated the drives using Windows XP. Something about "cylinder aligned as opposed to sector aligned". I don't remember exactly but Ghost 2003 works with one but not the other.

I actually installed Windows XP first, creating and formating all partitions. Next, I installed Windows 7 (replacing Windows XP), reformating in the process but keeping all partitions as created from within Windows XP.

I have to find that old thread and re-read it.

@ Christer

WinXP creates Cylinder aligned partitions and they are compatible with Ghost 2003. So for your purposes that is correct. But the Advanced Format HDs may be a different matter.

Yes, it seems like it's not "straight forward".

I found An update that improves the compatibility of Windows 7 and Windows Server 2008 R2 with Advanced Format Disks is available which seems to be included in Windows 7 SP1 and may therefore be history but it indicates that it's an issue in development.

Hitachi has the Hitachi Align Tool with a "questionnaire" to find out whether you need to use it or not.

If your answers are:
OS = Windows XP
Use cloning utility = Yes as well as No
Primary or Secondary = Primary
How many partitions = >1
then you need to use the tool.

If your answers are:
OS = Windows 7
Use cloning utility = Yes
Primary or Secondary = Primary
How many partitions = >1
then you need to use the tool.

If your answers are:
OS = Windows 7
Use cloning utility = No
Primary or Secondary = Primary
How many partitions = >1
then you do not need to use the tool.

I wonder if the result is the same for Windows 7 SP1 as w/o SP1 (KB982018 installed or not, included in SP1)? Comparing the results for Vista with and w/o "SP1 or higher" leaves you none the wiser. Vista requires use of the tool no matter what. Maybe the Hitachi Article is outdated?

(It seems like I will use a 512-byte sector harddisk in this build that I'm planning.)

@ Christer


Christer wrote on Jan 25^th, 2012 at 3:57pm:

Now, the new drives have 4 kB sectors with 512-byte emulation. I have read the Advanced Format Technology Brief from Hitachi but am not sure that I understand.

Okay, I briefly scanned that information--and I was left confused by it myself as well.

Quoting from that PDF file:


Quote:

In order to ease the transition, current Advanced Format drives provide 512-byte emulation (512e) at the drive interface for backward compatibility with legacy applications.

So, before we continue too much further with this discussion--is *Advanced Format Technology* a software or a *hardware* based technology?

The above quote seems to be saying that a HDD with this technology is *hard wired*--and to be compatible with *legacy* programs (software), the HDD will pretend (emulate) to use 512-byte formatting, but really that is being *overlaid* on the underlying 4096 (4K) functionality of the HDD hardware.  And that *emulation* function is where you can take a *hit* on performance?

So, if you do not purchase a HDD with *Advanced Format Technology*, then the discussion becomes mute?  Everything will function in the old style 512-byte technology?

But, it looks like you can use newer formatting tools (software) like *Boot It, Bare Metal* (BIBM), to *align* one's data on a non-*Advanced Format Technology* HDDs--does that make any sense to consider?


Quote:

To be able to get Ghost 2003 working with Windows 7, one of the things to remember when installing Windows 7 is to pre-partition and pre-format the drive from within e.g. Windows XP to get the partitions aligned correctly.

Here's a couple links I have saved regarding this (these?) issues:

Ghost 2003 strategy for Windows 7    


Christer wrote on Feb 11^th, 2010 at 3:34pm:

I start with a new HDD [0] and install the OS. During the installation I create the primary partition [C:] and format it NTFS. When the installation is complete, I create an extended partition with a single logical drive [D:] and format it NTFS.

And Brian replied:


Brian wrote on Feb 11^th, 2010 at 4:03pm:

Don't do this or Win7 will create a 100 MB System Reserved Partition which you don't need and is a pain. Create all your partitions before you let the Win7 DVD near your computer. This way the partitions will be cylinder aligned and compatible with Ghost 2003.

Ghost 2003 is a pre-Vista and Win7 version of Ghost--so it is only *aware* of the old way of creating a Master Boot region--i.e. the first 63 sectors--or what is called the first *cylinder head*.  With the advent of Vista and Win7, it looks like the Master Boot region is now set to the first 1 MiB (2048 sectors?) if you use the partitioning tool that comes with the installation disk (DiskPart), and this sets the necessary *alignment* that allows the software to use the 4096-byte (4 KiB) physical sectors that match the new *Advanced Format Technology* harddrive hardware.

Here are a couple links with interesting information about all this:

http://rodsbooks.com/gdisk/advice.html  

See the *Partition Alignment Issues* section.

http://en.wikipedia.org/wiki/Logical_Disk_Manager 

See the *Compatibility problems* section with the *Compatibility problems with using a 1-MiB alignment boundary* and *Advantages of using a 1-MiB alignment boundary* sub-sections.

The other main issue besides *alignment* that using WinXP to pre-partition the HDD was to avoid having the default Win7 behavior of creating the SRP (System Reserve Partition) that has the boot information separated from the OS partition and is necessary for the the BitLocker encryption software only available on Win7 enterprise(?) or profession version--most of us do not have that version in hand!

Windows 7 and SRP    

So, if you are going to use the new technology HDDs that have *Advanced Format Technology*, then the default Ghost 2003 imaging will not restore the proper alignment if restoring to a new replacement HDD.  It probably will work if the HDD is formatted with the Win7 partitioning tool and you are restoring to that existing partition where Ghost 2003 does not have to create the partition prior to restoring.

How to Prevent Windows 7 from Creating a Hidden /Recovery /System Reserved Partition during Installation


An alternate way to use Ghost 2003 would be to *force* a sector by sector image of the HDD.  This would presumably restore the *exact* same layout to a new HDD--but, testing would have to be done to be sure!  This would have to be a *whole HDD* image, and it will be a large image size--even with compression, because all data as well as the *blank space* will be included in the final image--you won't be able to ignore hibernation or page file used space like in the default running of Ghost 2003's back up image.


 

NightOwl,
I'm always impressed by the time and effort you put into your responses, thanks!

I post this to let you know that, right now, I'm packing to get out of town for the weekend. I'll be back on Sunday evening.

I want to condition this discussion with a few caveats with respect to the referenced Hitachi tech brief.

First, keep in mind that how the term "aligned" is used depends on what you're using as a reference point.   Readers of Hitachi's tech brief might get confused by our previous discussions of "MB-aligned" vs "CHS-aligned" partitions, but that's not the kind of alignment Hitachi is concerned with here.  Hitachi is talking about how the old 512-byte sectors and new 4KB sectors line up with each other.

It should also go without saying, but let's be clear that we are not talking about *moving* any 512-byte sectors so they line up better, we're talking about choosing *which* 512-byte sectors to use (and which to leave idle) so the ones we use are used more efficiently.

And lastly, my understanding is this whole matter only concerns disks up to 2TB in size--IOW, new drives that can be manufactured with sectors internally 4KB in size but can pretend to the outside world as though they have 512-byte sectors.  The registers in the ATAPI spec restrict the maximum number of sectors it can work with, which corresponds to 2TB if you use 512-byte sectors.  A disk might have 4KB sectors comprising more than 2TB, but if you make those 4KB sectors emulate 512-byte sectors (512e) that doesn't increase the number of them you can use with a legacy BIOS, MBR, partition table or OS, so you're still limited to 2TB that you can use.  I might be wrong, but I don't think 512e applies to drives >2TB.

Even though the manufacturers are using new technology inside, there's a backward compatibility purpose to still look like the old technology from the outside, hence 512e.  While the newest OSs like Win7 can use disks larger than 2TB, I don't believe they're doing so through 512e, I think they're accessing those disks as 4KB sectors natively, sans emulation.  That's why I think you can only use the largest drives with the newest OSs--the older OSs don't have the disk drivers to understand 4KB sectors.  They can understand 512/512e but not 4KB.  Win7 understands all of those.

Now, this whole alignment issue, in the context Microsoft and Hitachi are talking about, has to do with how to make disk read/writes more efficient.  It's not about whether a particular OS will work or not--it will work (assuming 512e), but disk access might not be as efficient as it could be.

To understand the problem, consider a utility like my MBRsaver.com.  It can save a backup of LBA 0 (your MBR sector), from which you can later restore *just a portion* of the MBR.  For example, you can restore just the boot code or just the DiskID without overwriting your partition table.  There are times when that might be desirable.

However, in order to do that it can't just retrieve the backup and slap it back onto Sector 0 or you'd overwrite the partition table, too--which you might not want to do.  Furthermore, you can't write just the 4 bytes of the DiskID to the drive because the drive can only write whole sectors at a time.  Thus, my utility has to first read the existing contents of the full sector into a buffer, then patch in the DiskID from the backup, then write the entire buffer back to disk--boot code, DiskID, partition table, and all.

That's the same kind of problem AF faces.  Since AF technology reads/writes a whole 4KB sector at a time, you have to use a similar technique to rewrite a single 512-byte "emulated sector".  The drive has to read the entire 4KB sector, change just the one-eighth of it representing the one 512-byte emulated sector, and write back the entire 4KB.  See the brief, page 2: "512-byte Write (Read-Modify-Write)".  Contrast that with a legacy drive, in which data could be read/written 512 bytes at a time.

Okay, there's not much the drive manufacturer can do about that.  If you're going to emulate 512-byte sectors and write one at a time, that's what you're going to have to do.

However, modern OS's don't read/write one sector at a time.  They write multi-sector blocks or clusters at a time.  That's what Hitachi is pointing out at the bottom of page 2 of the brief.  Same problem as above, just at the file system level now.  IOW, to change just one small part of a file, the file system (NTFS or FAT32) is rewriting all 8 sectors of that cluster, not just the one 512-byte sector that changed.  So the fact AF drives can't write one 512e sector at a time isn't really much of a problem because the file system you're likely using isn't writing one at a time, it's writing 8 at a time.  What we want to avoid, though, is making the drive read-modify-write *two* 4KB sectors instead of one, just to rewrite a single cluster.  That's the example in Figure 6 on page 3.

That brings us to page 3 of the brief, "Partition Alignment".  More specifically, it's cluster alignment we're really after, but in NTFS partitions the clusters will line up right if the partition boundaries, in 512e terms, line up on the boundaries of the drive's internal 4KB sectors.  That's the kind of alignment (or misalignment) Hitachi is talking about here.  As Hitachi notes on page 3, partitions will be properly aligned if you create them with Vista or Win7, but not with XP.

FTR, it's worth noting that *NTFS* clusters will align if the partition boundaries are aligned, but that's not true if you format the partition FAT32.  You can align a FAT32 partition's boundaries but that doesn't mean the clusters will necessarily line up correctly.  That's the purpose behind BIBM's "Align for NTFS conversion" option (see Brian's link in Reply #1).

Christer wrote: "To be able to get Ghost 2003 working with Windows 7, one of the things to remember when installing Windows 7 is to pre-partition and pre-format the drive from within e.g. Windows XP to get the partitions aligned correctly."

As NightOwl suggested, I think Christer may be mixing up a couple different issues.

One is the SRP issue: pre-partition the disk to prevent Win7 automatically creating a SRP.  It doesn't matter for the SRP issue whether you CHS-align or MB-align the partitions, so it doesn't matter what partitioning tool you use.  Fdisk, Partition Magic, Win2000, WinXP, and most other popular tools create CHS-aligned partitions.  Vista and Win7's diskpart will create MB-aligned.  BING and BIBM can do either.

The other issue is whether Ghost 2003 can work with MB-aligned partitions.  Yes, it can.  It has no trouble at all with MB-alignment.  There may be some limitations caused by Vista/Win7's BCD, but that's not a partition alignment issue.  It also doesn't restore MB-alignment on an unpartitioned disk, but that's not a failure condition.  An image of a MB-aligned Win7 partition still works perfectly fine if it's restored to a CHS-aligned partition.  It might work better in a MB-aligned partition, but it will work either way.  Furthermore, you can always pre-partition the target with MB-aligned partitions if you want and have Ghost restore a partition image into those rather than recreating its own.

NightOwl wrote: "before we continue too much further with this discussion--is *Advanced Format Technology* a software or a *hardware* based technology?"

AF refers to a new way of arranging the magnetic bits on the disk strata.  Bear in mind that the magnetic bits consist of more than just your data, they include a lot of overhead (housekeeping stuff like sector headers and error checksums) as well as wasted space for gaps between sectors.  As Hitachi explains in the brief ("How Does Advanced Format Technology Work?"), they can cram in more data if they don't have so many headers and gaps.

AF is hardware technology that software has no control over.  It's a matter of how the drive's controller circuitry manages the bits on the platter surface.  Your computer's BIOS, CPU, and OS never access those bits directly, they get whatever the controller gives them.  It's trivial for the controller to manage them in 4KB chunks on one side and turn around and deliver them to the outside world as 512-byte chunks.  That's 512e.  It's not that different from how a controller on a current drive fakes the disk geometry to the outside world.

NightOwl: "So, if you do not purchase a HDD with *Advanced Format Technology*, then the discussion becomes mute?  Everything will function in the old style 512-byte technology?"

Everything is still going to function in the old 512-byte style whether or not you use an AF drive.  The OS really has no idea that an AF drive is anything different.  It sees an ordinary interface of 512-byte sectors.  That's why Terabyte downplays the impact AF technology will have on the typical end-user.  If you have an AF drive, though, you might be using it less efficiently than you could.

NightOwl: "it looks like you can use newer formatting tools (software) like *Boot It, Bare Metal* (BIBM), to *align* one's data on a non-*Advanced Format Technology* HDDs--does that make any sense to consider?"

Perhaps, though the performance improvement may be more theoretical than noticeable.  My understanding is Microsoft has been making revisions in how they place the MFT and swap file to take advantage of alignment, as well.  Because of the read-modify-write bottleneck, I would imagine misalignment could exact a dramatic performance hit on an AF drive.  I haven't noticed misalignment making much difference on current non-AF drives.

On SSDs, alignment is a must.  Even though they're not technically considered AF drives, you should treat them that way.  Because they're more sensitive to the number of write cycles, you really don't want to be doing more read-modify-write operations if you can avoid it.

And I trust you realize you can use Win7 just as readily as BIBM.  It's just a MB-aligned partition, which is what diskpart in Vista/Win7 creates, regardless of whether or not it's an AF drive.

NightOwl: "if you are going to use the new technology HDDs that have *Advanced Format Technology*, then the default Ghost 2003 imaging will not restore the proper alignment if restoring to a new replacement HDD."

AF has nothing to do with it.  Ghost 2003 is going to see a 512-byte/sector drive whether it's AF or not.  But Ghost 2003 will not create a MB-aligned partition, period.  So if you put Ghost in a situation where it has to create the partition before restoring the contents, it's always going to do it CHS-aligned.  Remember, you can CHS-align an AF drive; it's just not the best way to use it.  And you can pre-partition a target drive with MB-aligned partitions and Ghost will happily restore images into those partitions without upsetting the alignment.

NightOwl,

I read the pages you linked to and they confirm a lot of the information that I have found. Dan has already answered your questions better than I would have so, I'll just add that re-reading the old thread "Ghost 2003 strategy for Windows 7", especially post #35 juggled my memory. The "-fdsp switch" is the key to successfully restoring an image to the original source partition or to the original source disk. (I never got around to trying the BCDEdit route.) Pre-partitioning is the key to avoiding the SRP partition.

Dan,
I'm equally impressed by your answers, thanks!


Quote:

The other issue is whether Ghost 2003 can work with MB-aligned partitions.  Yes, it can.  It has no trouble at all with MB-alignment.  There may be some limitations caused by Vista/Win7's BCD, but that's not a partition alignment issue.  It also doesn't restore MB-alignment on an unpartitioned disk, but that's not a failure condition.  An image of a MB-aligned Win7 partition still works perfectly fine if it's restored to a CHS-aligned partition.  It might work better in a MB-aligned partition, but it will work either way.  Furthermore, you can always pre-partition the target with MB-aligned partitions if you want and have Ghost restore a partition image into those rather than recreating its own.

This convinces me that Ghost 2003 will work with the new AF drives. The situation with the "-fdsp switch" has meant that restoring to a new hard disk, would include pre-partitioning and installing Windows 7 prior to restoring the image. That way the disk will get its signature and the "-fdsp switch" makes sure that it does not get altered/deleted in the restore procedure.

The difference with the new AF hard disks is that I can no longer use Windows XP to pre-partition but any of the alternatives listed by you.


Quote:

Vista and Win7's diskpart will create MB-aligned.  BING and BIBM can do either.

As I understand Brians instructions in Reply #2,


Quote:

Using Diskpart.... boot from a Win7 disk at the Install Windows screen, press SHIFT F10 to get a Command prompt type diskpart and press Enter list disk select disk 0 (use the number relevant to your HD) list disk (there will be an * next to your selected disk) clean (use this if you want to delete all partitions on the selected HD) create partition primary size=80000 (use whatever size in MiB you desire) select partition 1 active format fs=ntfs quick  assign exit exit You are now ready to install Win7 into this partition. You can create other partitions (using Disk Management) after Win7 is installed.

that procedure will create an "aligned partition" and avoid the SRP-partition.

There's no need for creating all partitions, leaving no unallocated space, to avoid the SRP-partition, right?

Christer wrote on Jan 29^th, 2012 at 5:58pm:

There's no need for creating all partitions, leaving no unallocated space, to avoid the SRP-partition, right?

It doesn't matter if you have unallocated space either side of the partition. If you install Win 7 into that partition you won't get a SRP. The unallocated space will be unchanged.

Christer wrote on Jan 29^th, 2012 at 5:58pm:

The situation with the "-fdsp switch" has meant that restoring to a new hard disk, would include pre-partitioning and installing Windows 7 prior to restoring the image. That way the disk will get its signature and the "-fdsp switch" makes sure that it does not get altered/deleted in the restore procedure.

The "installing Windows 7" step seems unnecessarily excessive.  It sounds like the only reason you're doing that is to generate a DiskID.  If all you need is some random DiskID, you can manually type something in with a sector editor like Diskedit or Roadkil's Sector Editor.  Or if you want to restore the same DiskID as on the original source disk, there are a number of ways to do that.  (Did I mention my MBRsaver tool can do that?   ;)  That would be a whole lot quicker and easier than installing Win7 just to turn around and overwrite it.)

Also, IME Ghost 2003 doesn't overwrite the DiskID if you do a partition restore vs a disk restore.  I never do disk restores, and never use the -fdsp switch.

Christer wrote on Jan 29^th, 2012 at 5:58pm:

The difference with the new AF hard disks is that I can no longer use Windows XP to pre-partition

I'm not quite sure if you're under the impression AF technology prohibits pre-partitioning with XP.  It doesn't ... but it's just not a good idea.  So it would be more accurate to say, "I shouldn't use Windows XP to pre-partition."



Quote:

As I understand Brians instructions in Reply #2, [...] that procedure will create an "aligned partition" and avoid the SRP-partition.

Just to be clear, you don't avoid the SRP because of how you pre-partitioned, you avoid it because you pre-partitioned.  IOW, you avoid the SRP if partitions of any kind are already there when you tell the DVD to install Win7.

To maximize efficiency on an AF drive, the kind of alignment that actually matters is when the boundaries of the file system's allocation blocks (aka, clusters) line up with the drive's internal 4KB sectors.  That's the situation in Fig 5 of the Hitachi brief, as opposed to Fig 6 in which the clusters are misaligned.

So if it's cluster alignment that matters, why are we concerned about partition alignment?  Because partition alignment affects cluster alignment.  Formatting a NTFS partition always results in file allocation blocks that start or end on 1MB intervals (or 256 4KB intervals) from the beginning of the partition.  (It's part of the NTFS spec, I think.)  Thus, MB-aligning your partitions is an expedient way to get your file allocation blocks to end up optimally aligned for AF disks.

Note I'm deliberately avoiding mentioning a particular OS here.  The OS doesn't really matter.  You can create MB-aligned partitions and run XP or even Win2K in them, and you'll get the same benefits from AF disks.  The difference is whether you create your partitions with 2K/XP vs Vista/7.  Diskpart in Vista/7 was designed to anticipate the arrival of AF disks, so Microsoft changed how (or rather, where) it would position partitions.  Whereas 2K/XP created CHS-aligned partitions, Vista/7 MB-aligns them so they'd be optimally aligned in preparation for AF disks.

Incidentally, this is where I think many discussions--even the Hitachi brief--can be misleading because they refer to the OS rather than the file system.  They lead people to think you shouldn't run XP as your OS on an AF disk, and that's just not true.  XP should run fine.  But for maximum benefit you do want to make sure your partitions are MB-aligned, regardless of OS.  You can do that by creating your partitions with a Win7 DVD, or by using BIBM, or by using XP and then adjusting them with something like the Hitachi realignment tool.

As for the file system, all of the above is in reference to NTFS.  Things are different if you format FAT32 because MB-aligning the partition boundaries still doesn't guarantee the file clusters will also align.  In FAT file systems the clusters begin immediately after the FAT tables.  The size of the FATs are directly related to the size of the partition, so on partitions of different sizes the FATs will be different sizes, and the clusters will thus begin at some irregular spot within the partition.

Christer wrote on Jan 29^th, 2012 at 5:58pm:

The situation with the "-fdsp switch" has meant that restoring to a new hard disk, would include pre-partitioning and installing Windows 7 prior to restoring the image. That way the disk will get its signature and the "-fdsp switch" makes sure that it does not get altered/deleted in the restore procedure.

Christer, that sounds time consuming. I just ran this test.

Win7 in a MB aligned partition. BIBM was on the HD too but I don't think it interfered with the result.

I generalized the BCD with...

bcdedit /set {bootmgr} device boot      
bcdedit /set {default} device boot         
bcdedit /set {default} osdevice boot      
bcdedit /set {memdiag} device boot      

A Ghost 2003 partition image of Win7 was created.
The image was restored to unallocated space on an unpartitioned HD. A target partition size was chosen in Ghost. (the HD had been used before so it had a MBR)

Win7 on the new HD booted normally. Easy. No switches used.

Edit.... The above partition was cylinder aligned. I deleted the partition and created a MB aligned partition with BIBM. The same Win7 image was restored into this partition. Win7 booted and the partition remained MB aligned.

Brian,


Quote:

It doesn't matter if you have unallocated space either side of the partition. If you install Win 7 into that partition you won't get a SRP. The unallocated space will be unchanged.

The last time (1-2 years ago) we discussed this I misunderstood and thought that no unallocated space could be present but now I know differently.


Quote:

I generalized the BCD with... bcdedit /set {bootmgr} device boot       bcdedit /set {default} device boot          bcdedit /set {default} osdevice boot       bcdedit /set {memdiag} device boot

That's what I never got around to the last time ... :-[ ... maybe I'll try it this time using either BCDEdit or Dan's MBRsaver tool. I've started reading up on both of them.


Quote:

The above partition was cylinder aligned. I deleted the partition and created a MB aligned partition with BIBM. The same Win7 image was restored into this partition. Win7 booted and the partition remained MB aligned.

That confirms what Dan wrote in Reply #9:


Quote:

So if you put Ghost in a situation where it has to create the partition before restoring the contents, it's always going to do it CHS-aligned.  (...) And you can pre-partition a target drive with MB-aligned partitions and Ghost will happily restore images into those partitions without upsetting the alignment.

The only thing I have noticed the few times I created Disk-to-Image and restored Disk-from-Image is that even if I have pre-partitioned the new disk, Ghost will suggest different sizes even if the source disk and target disk are identical with identical partition sizes. When that happens, my bet is that the resized partitions (even if I choose the original sizes) will become CHS aligned. My experience is that Ghost 2003 never suggests different sizes when creating Partition-to-Image and restoring Partition-from-Image. Also, the "-fdsp switch" is not needed when working with the system partition, only when working with the whole disk.

Dan,


Quote:

The "installing Windows 7" step seems unnecessarily excessive.  It sounds like the only reason you're doing that is to generate a DiskID.  If all you need is some random DiskID, you can manually type something in with a sector editor like Diskedit or Roadkil's Sector Editor.  Or if you want to restore the same DiskID as on the original source disk, there are a number of ways to do that.

I don't know how the Windows 7 installer creates the DiskID but after an image restore, if it doesn't match, the OS won't boot. Ghost 2003 zeros the DiskID when restoring a Disk-from-Image and it worked with Windows XP and earlier OS. The BCD edit that Brian and you discuss will fix this (Windows 7 will boot without a correct DiskID) and I will try that when the components get here.


Quote:

Also, IME Ghost 2003 doesn't overwrite the DiskID if you do a partition restore vs a disk restore.

I agree. I have only created and tested restoring Disk-from-Image to learn and make sure it works. I have never restored out of necessity.

Now I don't understand how a partition restore to a new hard disk (pre-partitioned or not) will boot? The BCD is not included in the partition image ... :-? ... and is needed for it to work, right? That's why I "insist" on first installing Windows 7 on the new hard disk and next restore partition-from-MyTrustedOldImage. It also avoids the "automatic resizing issue" that I discussed in my reply to Brian.


Quote:

I'm not quite sure if you're under the impression AF technology prohibits pre-partitioning with XP.  It doesn't ... but it's just not a good idea.  So it would be more accurate to say, "I shouldn't use Windows XP to pre-partition."

Yes, I know. I have read that the performance hit can be substantial if the partitions aren't "properly" aligned. If you compare the performance of the Hitachi 500 GB 7K1000.D with performance of the 500 GB 7K1000.C (assumingly affected by misalignment):

Max data transfer rate = 1822/1546 Mb/s > + 18%

I don't know if + 18% is more or less signinficant than the performance hit from misalignment but my thought was that if I don't get it right, I can stick with the previous generation and stop worrying ... 8-) ... !

Christer wrote on Jan 30^th, 2012 at 7:31am:

I generalized the BCD with... bcdedit /set {bootmgr} device boot bcdedit /set {default} device boot bcdedit /set {default} osdevice boot bcdedit /set {memdiag} device boot That's what I never got around to the last time ... Embarrassed ... maybe I'll try it this time using either BCDEdit or Dan's MBRsaver tool. I've started reading up on both of them.

I put those 4 lines in a batch file in Win7 and Ran as Administrator. Dan's MBRsaver has nothing to do with BCDEdit if you are confused about the two.


Christer wrote on Jan 30^th, 2012 at 8:12am:

I don't know how the Windows 7 installer creates the DiskID but after an image restore, if it doesn't match, the OS won't boot.

That is a fallacy. In my test above each HD had a different DiskID (the DiskID on the new HD wasn't changed by the restore) and the new Win7 booted normally. I've seen this after restoring partition images with Ghost 2003, Ghost 15 and TeraByte Unlimited to new HDs.


Christer wrote on Jan 30^th, 2012 at 8:12am:

The BCD is not included in the partition image ...

I think you are confused about the BCD. It is part of Win7 and is not in the MBR. See this web page about moving the BCD...

http://www.terabyteunlimited.com/kb/article.php?id=409

As Dan mentioned, if you mistakenly restore a partition as cylinder aligned it can be converted to a MB aligned partition without repeating the restore.

Edit... As discussed in another thread, I could restore a Ghost 2003 image to unallocated space on a HD because that HD had been previously Initialized. It had Boot Code and a DiskID. Ghost 2003 can't restore a partition image to a HD that hasn't been Initialized.

Christer, one hiccup. BIBM was helping, marginally.

I repeated the test with BIBM uninstalled. New Win7 didn't boot but this was simply due to Win7 not being set Active by Ghost 2003. After setting the partition Active, Win7 booted.

So it seems a simple matter to restore a Ghost 2003 image of a MB aligned Win7 partition to a new HD.

Christer wrote on Jan 30^th, 2012 at 8:12am:

The BCD is not included in the partition image [...] and is needed for it to work, right?

The BCD is a file in the Win7 partition, so Ghost 2003 will backup/restore it just like any other file.

Win7's BCD serves the same purpose as XP's boot.ini file, except that in typical Microsoft fashion, they turned what used to be a plain text file (boot.ini) into a non-human readable binary file.  That's why you now need special tools to edit the BCD.

A salient point to this thread is that Ghost knew what a boot.ini file was for, and it would make adjustments to it if that was necessary for the restored OS to be bootable.  However, Ghost 2003 knows nothing about what a BCD file is for, so while it can back it up and restore it, it will not know to make any adjustments to it if necessary.

That's one of the points behind the "BCD generalization" steps Brian has outlined.  If you don't have a SRP and you generalize the BCD, then Ghost 2003 wouldn't need to have to make any changes to it--which is convenient because we know that wouldn't happen anyway.

If it helps, I'll describe a technique I have used to quickly backup/restore a Win7 system with Ghost 2003.  For illustration, I'll use as an example a brand new Dell/Win7 PC, which comes from the factory with a small DellUtility partition, a 10-20GB Recovery partition, and a main OS partition occupying the rest of the space.

To be able to completely restore a disk to OEM condition, there are four pieces of the OEM HDD to backup: the three partitions plus Track-0.  I use Ghost 2003 to make partition-to-image backups of the three partitions, and use something like Terabyte's MBRwork utility to backup the first 63 sectors (Track-0) of the disk.

That's all.  It's pretty straightforward, and I can then go about repartitioning and customizing things as I like.

If/when I want to restore the disk back to OEM condition (perhaps to resell it or pass it down to a relative), all I have to do is restore the Track-0 backup, reboot (so the new partition table is recognized), and do three partition-from-image restores.

The Track-0 backup captures/restores the MBR, the DiskID, the partition table, the active partition boot flag, and any extra proprietary boot track sectors an OEM might have added.  (Dell and HP, for example, can hide additional code to facilitate booting their Recovery partitions.)  Thus, restoring the OEM Track-0 on a new, blank HDD effectively lays out the partition boundaries to be identical to the OEM HDD--even MB-aligned if the OEM was MB-aligned.  With the empty partitions thus laid out, Ghost 2003 will restore partition images into them without disturbing the alignment.

I've used this technique more than a few times, and can verify it works.

@ Dan Goodell


Dan Goodell wrote on Jan 30^th, 2012 at 11:54pm:

If it helps

Now you did it--opened a whole new *can of worms*!


Dan Goodell wrote on Jan 30^th, 2012 at 11:54pm:

For illustration, I'll use as an example a brand new Dell/Win7 PC, which comes from the factory with a small DellUtility partition, a 10-20GB Recovery partition, and a main OS partition occupying the rest of the space.

So, it's a Win7 system, but Dell is not using the System Reserved Partition (SRP) with the boot files that would occur if I were installing Win7, using its default installation settings, on my own personally built system?

So the *boot configuration data* (BCD) file is on the main Win7 OS partition?


Dan Goodell wrote on Jan 30^th, 2012 at 11:54pm:

and use something like Terabyte's MBRwork utility to backup the first 63 sectors (Track-0) of the disk

If I understood some of what was being presented in this link:


NightOwl wrote on Jan 26^th, 2012 at 12:58pm:

http://en.wikipedia.org/wiki/Logical_Disk_Manager

it sounded like from Win Vista onward, the MBR is now:


Quote:

The "starting offset" refers to the sectors before the partition. "3F" is a hexadecimal value; in decimal that is "63". This is the size of one head (or "track") in terms of a standard CHS geometry. The hex value "800", in decimal form is 2048, so this is referring to the first MiB of space, from the start of the disk. Because a 1-MiB alignment boundary is used by the Vista partitioner(s), 1 MiB is "reserved for" the Master boot record (MBR), instead of the traditional 63 sectors (31.5 KiB).

And using the 1-MiB for the reserved space at the beginning of the HDD for the MBR was necessary to offer alignment of the rest of the HDD.

So, is the Dell system not *aligned*? 

If the MBR reserved area is 1-MiB (2048 sectors)--is there a chance you might not capture all the *extra proprietary boot track sectors an OEM might have added* if they extend beyond the first 63 sectors?



Quote:

Thus, restoring the OEM Track-0 on a new, blank HDD effectively lays out the partition boundaries to be identical to the OEM HDD--even MB-aligned if the OEM was MB-aligned.

The MBR only uses the first absolute sector 0--does restoring that automatically restore the 1-MiB boot track region that also sets up the alignment of the HDD again?

Brian,


Quote:

Dan's MBRsaver has nothing to do with BCDEdit if you are confused about the two.

I know that BCDEdit is native to Windows 7 but Dan informed that his tool could do the job too.


Quote:

I think you are confused about the BCD.

Yes, I'm still thinking too much XP ... :-[ ... !

Quote:

So it seems a simple matter to restore a Ghost 2003 image of a MB aligned Win7 partition to a new HD.

Yes, once all the fall traps are closed.

NightOwl wrote on Feb 1^st, 2012 at 1:40am:

So the *boot configuration data* (BCD) file is on the main Win7 OS partition?

The BCD is a file in the "\Boot" folder of the active partition.  In a split SRP+OS system that puts it on the SRP, while on a system where the OS partition is the active partition the BCD is there.



Quote:

So, it's a Win7 system, but Dell is not using the System Reserved Partition (SRP) with the boot files that would occur if I were installing Win7, using its default installation settings, on my own personally built system?

On Dell's Win7 systems the Recovery partition doubles as a SRP, so Win7 boots via the Recovery partition.  On Dell's Vista systems the OS partition is the active partition, so the Recovery partition boots via the OS partition.

But that's not the point.  My point is all those details are immaterial if you're just trying to duplicate an existing system.  It doesn't matter whether you have a SRP, or a Recovery partition, or neither, or which one is the active partition, or whether it's CHS-aligned or MB-aligned ... it's all immaterial if all you're doing is making an exact clone.  And Ghost 2003 can easily do that with a backup of Track-0 and partition images.



Quote:

sounded like from Win Vista onward, [...] 1 MiB is "reserved for" the Master boot record (MBR), instead of the traditional 63 sectors (31.5 KiB).

The "MBR", like "drive", has never had a precise definition, and unfortunately it sounds like they're trying to unilaterally redefine it according to somebody's personal preference.

Most people say the Master Boot Sector (the first sector on the HDD) is the MBR, others say only the boot code part of that sector is the MBR.  Systems with multiboot managers (like Grub, BING/BIBM, Acronis Secure Zone, et al) use more than one sector and often refer to the extra sectors as an "extended boot record" or "MBR extension".  IAC, those terms have generally referred to just the amount of sectors that were necessary to contain all the code, not the entirety of empty space before the first partition.  I've never heard of the empty sectors being referred to as the MBR, and just because you move the first partition further away from the front doesn't mean you now have a larger MBR to backup.

Remember my MBR backgrounder: the IPL boot code merely turns control over to a PBR.  Nothing more.  If you have a true boot manager you might have to use more than a single sector to do it, but the end result is still the same: pass control to a PBR, regardless of what OS is on it.  FTR, note that the standard MBR code installed by the Win7 installation process still fits in a single sector--just like Vista, XP, Win98, and DOS.  Changing where you place your partitions doesn't change the definition of the MBR.



Quote:

And using the 1-MiB for the reserved space at the beginning of the HDD for the MBR was necessary to offer alignment of the rest of the HDD.

Keep your eye on the ball, NightOwl: HDDs do not get aligned.  We align partitions, not HDDs.  And the only reason we align partitions is because that aligns clusters, which is the only factor that actually matters.

Don't think of it as "reserving 1MB"--you're not "reserving" anything.  You're using 1 sector for the MBR, and then positioning your first partition at the earliest multiple of 2048 sectors that you can, following the MBR.



Quote:

If the MBR reserved area is 1-MiB (2048 sectors)--is there a chance you might not capture all the *extra proprietary boot track sectors an OEM might have added* if they extend beyond the first 63 sectors?

Yes, if anybody used more than 63 sectors, but I've never seen any manufacturer use more than about 14 or 15 sectors.  You can capture 2048 if you want, but all you're going to get are more zeroes.

You could also cause potential restore problems if you capture 2048 and your first partition is CHS-aligned, because then your backup overlaps your first partition.  For that reason, and because sectors 63-2048 will never contain MBR code anyway, I make it a habit to never backup more than the first 63 sectors.



Quote:

So, is the Dell system not *aligned*?

Again, remember that it's partitions that get aligned.  Dell's Vista and Win7 systems use a 1-sector MBR, a CHS-aligned Utility partition, and MB-aligned Recovery and OS partitions.

Remember that the goal is to align NTFS clusters because Windows writes whole clusters at a time.  The fact Dell CHS-aligns their Utility partition is inconsequential because it's not NTFS and because it's not even accessible to Windows anyway.

Dan,


Quote:

The BCD is a file in the Win7 partition, so Ghost 2003 will backup/restore it just like any other file.

Yes, like I confessed to Brian, Im still thinking too much XP ... :-[ ... !

Quote:

However, Ghost 2003 knows nothing about what a BCD file is for, so while it can back it up and restore it, it will not know to make any adjustments to it if necessary. That's one of the points behind the "BCD generalization" steps Brian has outlined.

I certainly will try that route with this build.

Regarding Reply #20, NightOwl has already asked the questions which you already have answered.

Christer wrote on Feb 1^st, 2012 at 3:37am:

I know that BCDEdit is native to Windows 7 but Dan informed that his tool could do the job too.

I don't think I did.  Are you referring to Reply #12?

"Or if you want to restore the same DiskID as on the original source disk, there are a number of ways to do that.  (Did I mention my MBRsaver tool can do that?"

MBRsaver can individually restore any of the three parts of the Master Boot Sector--the boot code, the DiskID, or the partition table.  Most MBR utilities can only do all three together.  MBRsaver doesn't get involved in any other sector of the hard drive.

The BCD isn't part of the MBR, it's a file on the active partition.

Dan,

When using MBRsaver is there a simple method of knowing which HD you are dealing with? I use MBRSaver from a USB flash drive and I use

dsrfix /80
dsrfix /81
etc

to identify my BIOS HD0 in a 3 HD computer. The relevant  HD is /81. Without using this switch I would save the MBR of the flash drive which is /80.

Dan,


Quote:

I don't think I did.  Are you referring to Reply #12?

Yes, I was too quick about re-reading your reply. The issue with the DiskID is a different matter. The DiskID can be edited using your tool "MBRsaver". Using Brian's "generalized BCD" (edited using BCDEdit) avoids the problem (as well as the use of the "-fdsp switch").

I'm dual booting (Win XP pro - Win 7 pro) and I now realize that's possibly why it takes three experienced forum members a thread of several pages to get it through to me ... ;D ... !

Brian wrote on Feb 1^st, 2012 at 4:25am:

When using MBRsaver is there a simple method of knowing which HD you are dealing with?

Unfortunately, no.  That's something I never got around to putting in MBRsaver.

I originally created MBRsaver over a decade ago.  That was during the days when I was exploring how Win2K remembered drive letters, and it was handy to have a quick-and-dirty way to restore just a HDD's DiskID by itself.  I always knew which device ID I was working with while I was up to my elbows in some project, but it's admittedly user-unfriendly for everyday use or coming in blind on some random system.  There's a few improvements like that which could be added, but it's just never been high enough on my priority list to get around to it.



Quote:

I use dsrfix /80 dsrfix /81 etc to identify my BIOS HD0 in a 3 HD computer.

Yeah, I do the same thing.  If I'm working on a multi-HDD system and not sure which BIOS ID I want, I trial-and-error it with Dsrfix to see whether it's /80 or /81, etc., then use the same switch with MBRsaver.