MyTechSupport.ca :: Your Computer Technical Resource Headquarters! MyTechSupport.ca :: Your Computer Technical Resource Headquarters!
HOME FORUMS RESOURCES & TOOLS ARTICLES ONLINE STORE ABOUT US
Computer Support Forums arrow Computer Related Discussions arrow Tips & Tricks arrow Topic: The difference between Vista created partitions and Pre-Vista created partitions
March 22, 2019, 09:56:04 PM
 

Home Forum Rules Help Search Mobile Version Login Register

Welcome, Guest. Please login or register.
Did you miss your activation email?
March 22, 2019, 09:56:04 PM

Login with username, password and session length
 
News
New  New Poll on our main page!
"My experience with Vista..."
  0 Members and 1 Guest are viewing this topic.
Pages: [1] Go Down Print
Author Topic: The difference between Vista created partitions and Pre-Vista created partitions  (Read 4591 times)
Doctor Smith
Hero Member
*****

Karma: +0/-0
Offline Offline

Posts: 718


Dumb questions welcomed


Bookmark and Share

View Profile
« on: June 15, 2008, 05:20:26 PM »

The difference between Vista created partitions and Pre-Vista created partitions.

First, a little background information.

all hard disks are made up of sectors. Each sector has a number, the first sector being number 0 (zero). So sector 10 is simply the 11th sector on the disk (start at 0!) and so on. This type of numbering is called LBA addressing. LBA stands for 'Logical Block Address', which in this case simply means that sectors can be found on the disk by counting from the start of the disk. A simple clean system.

In earlier days, when disks were smaller, an additional system was used to define a location on a disk: the CHS notation. CHS stands for Cylinder, Head and Sector. Mechanically speaking, hard disks contain platters and each platter has it's own set of read/write heads. If you'd put the heads in a certain position above the platters and perform a read operation on all the heads, you would have read a cross section of the disk. A stack of rings if you will, one ring for each platter. This would be called a cylinder. Each cylinder would be numbered, the first one being 0 (zero). The read/write heads are also numbered (again, the first one being 0), so you can use a cylinder number and a head number to find a specific location on the platters. Finally, each of the rings we've read earlier consist of a number of sectors, which also have a number (sector numbers start at 1, not 0). So a CHS address of 9-0-1 would translate into reading the sector at cylinder 9, head 0 and sector 1 (remember: cylinder and head starts at 0, sectors start at 1). The maximum number of sectors in a ring would be 63 (from 1 to 63), the maximum number of heads would be 255 (from 0 to 254) and cylinders could be any number, so as disks got bigger the number of cylinders grew and grew. Of course there were almost never any disks that actually had 255 heads, this number was selected because at the time they thought it would be more than enough to accommodate even the largest disks. Obviously they were wrong...
This CHS notation is still in use today, but only because of backwards compatibility reasons: most recent operating systems don't use these numbers anymore. Since disks these days are quite big, disk manufacturers almost always set the number of sectors per ring to 63 (the max possible value) and the number of heads per cylinder to 255 (again, the max possible value). If you'd make these numbers smaller you could get a huge number of cylinders so it makes sense to select the highest possible values for heads and sectors: bigger chunks are easier to manage. For this reason most modern day disks will tell you that they have 63 sectors per head and 255 heads per cylinder, even if in fact that's not the way the disk is made up.

So what does this have to do with partitions?
All Windows versions before Windows Vista used these CHS numbers to select the start- and end location for a partition: a partition would always start on the first sector of a head location, and the partition would always end at a cylinder end location. Example: let's say we have a disk that has 63 sectors per ring, 255 heads per cylinder and 1000 cylinders. A start location for a partition could be 0-1-1 (cylinder 0, head 1, the first sector) and an end location could be 74-254-63 (cylinder 74, head 254 and sector 63). In this example 254 is the highest possible head number and 63 is the highest possible sector number: if you continue to the next sector these values would roll back their starting values, and the cylinder number would increase by 1. That's why we call this type of location (head 254 and sector 63) a 'cylinder end location'.
For this reason a partition would never be the exact size that you selected: during creation a partition was stretched or shrunk to make sure the start- and end locations would be according to the rules as explained above.

If a partition is created according to these rules, a partition is 'CHS aligned'.

Windows Vista ignores the whole CHS nightmare and uses only LBA addressing, so Vista starts counting at sector 0 and simply sequentially counts onwards. A new formula is introduced to determine the start- and end locations for partitions: a start location is always a multiple of 2048, an end location is always a multiple of 2048 minus 1. Nice and simple. The number 2048 was selected for a reason: 1 sector contains 512 bytes so 2048 sectors is exactly 1 megabyte. So if you select to create a partition of x megabytes in Windows Vista, it will be exactly that size in megabytes.

If a partition is created according to these rules, a partition is 'megabyte aligned'.

And finally, what does all this have to do with DiskPatch?
DiskPatch uses a clever scheme to search the disk for partition remnants. As you can see from the explanation above, it's imperative that DiskPatch knows where to search. Therefore DiskPatch needs to know if the partitions were created using Windows Vista (so DiskPatch can look at LBA locations that are a multiple of 2048) or if the partitions were created using earlier versions of Windows (so DiskPatch can look at the correct CHS locations). If you would let DiskPatch scan a Vista disk in CHS mode it's likely that nothing would be found, so it's essential that you select the correct search method. Also, if DiskPatch accidentally finds stuff while using the wrong search method, the repair would probably lead to partitions that can't be accessed, or partitions may even be damaged by the actual repair. For this reason you should always enable the Undo feature, and make sure you use the correct scanning method.

-----------------------------------------------------------------------------------------------------------------


Megabyte 2048-aligned partition and cylinder 63-aligned legacy partitions

"The interesting thing about restoring the Vista Primary Partition (3rd one) onto a old SATA drive which I deleted the xp partitions, is that I ONLY restored the Vista Primary Partition.  and yet the old SATA drive booted fine without any intervention or repairs etc.

That's a lot better than all the lengthy threads I have been following on the TI forum regarding offsets and repairs and TI."


There seems to be a widespread misconception that the partition structure/location requirements are different for Vista vs. XP/earlier.  That's not so.  Vista works just fine in "normal" (let's call it legacy) partitions.  There is no mystery that a restored Vista partition should work in a legacy partition.  An image of a Vista OS partition, regardless of whether the original was 2048-offset or 63-offset, can be restored and work just fine on another partition, whether 2048- or 63-offset, or even something entirely different.  We all know an image of an XP partition can be restored to a different location on a disk, and the principle is the same here.  It doesn't matter what the offsets of the source or the target are.

What is different is the location of partitions that are created with the Vista partitioning programs.  It's important to separate this concept from Vista itself--don't think of it as a feature/requirement of Vista, it's a characteristic of the partitioning utility.  The Vista operating system doesn't care whether it's a 2048-offset or a 63-offset partition.  IOW, you can create a legacy partition with XP, PM8, or even fdisk, and Vista can be installed in that pre-created partition without any problem.  If you're creating the partition during the Vista install, however, then you're using the Vista partitioning utility, and that does not create legacy partitions.  Either way, the OS doesn't care.

Legacy partitions begin and end on cylinder boundaries.  "Cylinders" are a virtual concept, and have had no real meaning since the advent of IDE hard disks around a decade and a half ago.  The one exception to the cylinder-boundary rule is when the beginning of a cylinder needs to have a partition table, such as the very beginning of the disk (space needed for MBR/partition table) or the beginning of a logical partition (space needed for extended partition table--what PM8 refers to as an EPBR).  In those cases, the following partition starts one "track" (another virtual concept) later.  Most disk manufacturers implement the notion of tracks with 63 sectors--hence, the familiar 63-sector offset practice to which we have all become accustomed.

But remember, the notion of cylinders and tracks has been obsolete for a long time, and disks have just been faking it all these years.  Utilities like PM8, ptedit, and partinfo, as well as nearly every other utility in the world, have continued the charade to avoid upsetting old operating systems.  The Vista disk partitioner simply says to heck with old operating systems and abandons the concept altogether.

Rather than cylinders and tracks, think of the Vista partitioner as using units or blocks of 2048 sectors.  (Assorted TI threads have links to the Microsoft pages attempting to explain how they came up with 2048, but that's not important here.  The important thing is Vista can use anything, and Microsoft has settled on 2048, like it or not.)  The Vista partitioner will create partitions that align on 2048-sector blocks.  If a block has a partition table, the following partition will begin one block--2048 sectors--later.  Pretty simple.

Now, what's confusing everyone is that legacy utilities will continue to display partition information as though they were legacy partitions, with cylinders and tracks.  They're not wrong, but it is confusing.  They're not wrong because disks still use legacy partition tables (for now), so the Vista partitioner has to create those (ahem) "wrong" numbers to put in the legacy partition table.  So the Vista partitioner manufactures numbers than look wrong, puts them in the partition table, the legacy tools read those numbers, and show them to you.  No wonder you get confused.

This is a long-winded way of saying you don't need to avoid the legacy tools, but you do need to understand what they are showing you.  The only numbers that are really relevant are the sector-offset and partition size.  Sector-offset is denoted as "Sectors Before" in ptedit and "Hidden Sectors" in PartInfo.  The size of the partition in sectors is shown as "Sectors" in ptedit and "Total Sectors" in PartInfo.

For an illustration of how this all plays out, let's consider Ghost4me's original Dell hard disk.

The first primary partition was created with a legacy utility.  We know the MBR/partition table is on cyl/hd/sec 0/0/1.  (Remember, it's still a legacy partition table, so it's going to show cyl/head/sec values, even though the numbers are imaginary).  That means the first legacy partition cannot start before CHS 0/1/1.  This disk's parameters are 38913 cylinders, 255 heads (tracks) per cylinder, and 63 sectors/track.  LBA sector numbers are zero-based, so CHS 0/1/1 is equivalent to LBA-63--the "offset" shown in the partition table.

Having been created with a legacy utility, the first partition ends on the boundary between cylinder 5 and 6, offset 96390 sectors (63+96327) from the partition table.  Note that one cylinder is 16065 sectors (255*63), and 6 full cylinders (cyls 0-5) would be 96390 sectors (16065*6).  All the numbers fit.

A legacy partitioner would start the second partition at CHS 6/0/1, or LBA-96390 (and that's what you'd see on the old XP systems).  However, the second partition was created with the Vista partitioner.  The Vista partitioner interpets partition-1 as ending in the middle of a 2048-sector block:  96390/2048 = 47.07 blocks.  So partition-2 is created beginning with the next full block.  48*2048=98304, so the next full block begins on the 98305th sector, which is 98304 sectors offset from the first sector, where the partition table is.  In CHS terms, the 98305th sector (LBA-98304 in the zero-based LBA enumeration) translates to CHS 6/30/25:  (6*16065)+(30*63)+25 = 98305.  But remember, the Vista partitioner--and the Vista OS--don't care about imaginary CHS boundaries.

You can do the math for the rest of the numbers:

Partition-2 ends at LBA-sector 21,069,824 (98304+20971520), and 21069824/2048=10,288 full blocks.

Partition-3 begins at offset 21,069,824, and ends at 343,117,824 (21069824+322048000), which is 167,538 full blocks into the disk.

Partition-4 begins at offset 343,117,824 and ends at 625,139,712, which is 305,244 full blocks into the disk.

Now, realize that partition-4 is an extended partition (type 0F).  That means the primary partition table actually points to an extended partition table, which precedes the logical partition itself.  So, "partition-4", which begins on LBA-343117824, is actually another partition table.  The logical partition begins one block later--an offset of 2048 sectors from the extended partition table, not from the primary partition table.  (FTR, a legacy partitioner would have placed the logical partition 63 sectors after the extended partition table.)

Ghost4me should note that the PartInfo report does not show the extended partition in the "Boot Sector Information" part of the report, it shows the logical volume that is within the extended partition.  Hence, the 2048 "Hidden Sectors" and the file system ID of 0x07.  IOW, there is no inconsistency between ptedit and PartInfo, as long as you understand what they are showing you.

As for why an image of the original 2048-offset partition restores as a 63-offset partition, consider the partitioner.  When you restore an image on a blank disk, Ghost must create a partition first, then fill it with the contents of the image.  Ghost is the partitioner.  And it's creating partitions the legacy way.  But, again, it doesn't matter to the OS.
Logged




Pages: [1] Go Up Print 
 
Jump to:  

Powered by MySQL Powered by PHP

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS!

Disclaimer
This site is NOT responsible for any damage that the information on this site may cause to your system. Everything you try, whether inspired by the response given from this site or not, is entirely at your own risk. All product names and company names used herein are for identification purpose only and may be trademarks or registered trademarks of their respective owners. We are in no way affiliated or representing any of the companies on this site unless specified.
Back to Top
Stop Spam Harvesters, Join Project Honey Pot Fight Back Against Spammers! Get Firefox! Get Thunderbird! View Sylvain Amyots profile on LinkedIn
Back to Top
Google visited last this page Today at 01:35:36 PM