Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

[Solved] Double HDD Capacity Showing

- - - - -

  • Please log in to reply
11 replies to this topic

#1
j7n

j7n

    Member

  • Member
  • PipPip
  • 290 posts
  • Joined 18-December 06
  • OS:XP Pro x86
  • Country: Country Flag
I repartitioned my PATA hard drive connected via VIA VT6410 using GParted v0.13.1-git, and re-installed Windows XP SP3, after accidentally deleting the previous operating system. Partitioning involved deleting the primary partition, deleting a logical partition, and downsizing the extended partition to free up more space for a slightly larger new primary one.

Now the drive is showing double the actual capacity and non-existant Unallocate space in XP's Logical Disk Manager.

Posted Image

Posted Image

There don't seem to be any issues with accessing files, nor the disk at block level. Assuming I don' t attempt to use the Windows disk manager. The other SDA drive contains intentionally disabled partitions, and is supposed to look this way.

The odd thing about the disk layout is that the SWAP partition is on a later entry in the Extended partition, except being physically located before D and E, since it was added later. I created this situation accidentally, but this causes Windows 98 (which works properly) to assign drive letter F to it (and put it at the end of the disk list). (not true anymore, the SWAP parition is now listed between D and F)

I tried a few RAID driver versions. Have you seen anything like this?

Edited by j7n, 02 May 2013 - 10:19 AM.



How to remove advertisement from MSFN

#2
Ponch

Ponch

    MSFN Junkie

  • Patrons
  • 3,314 posts
  • Joined 23-November 05
  • OS:none specified
  • Country: Country Flag
It says "unallocated space", it's the sum of the unpartitioned space and the free space within in the extended partition. (125.22GB + 102.66GB) x 1024 = 233345 MB
I don't see an other problem ? If you don't give the actual capacity, we can't see where it's "double".

#3
j7n

j7n

    Member

  • Member
  • PipPip
  • 290 posts
  • Joined 18-December 06
  • OS:XP Pro x86
  • Country: Country Flag
The actual capacity is about 233 GB.

GUI GParted, which is the exact same version I first used, now refuses to recognize the drive, complaining about "overlapping partitions". I guess the partition table should be cleaned up, but I am not sure how to proceed with it without losing data from "Programs" and "Files".

fdisk -l /dev/sdb

omitting empty partition (5)
Partition 5 is deleted

Disk /dev/sdb: 250.1 GB, 250058268160 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488395055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa129a129

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     8386559     4192256    b  W95 FAT32
/dev/sdb2         8386560   488392703   240003072    f  W95 Ext'd (LBA)
/dev/sdb3        20980953   225793574   102406311    b  W95 FAT32
/dev/sdb5         8388608    10502143     1056768    b  W95 FAT32
/dev/sdb6       225793638   488392064   131299213+   b  W95 FAT32


#4
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,802 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Let's try reading these data:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     8386559     4192256    b  W95 FAT32
/dev/sdb2         8386560   488392703   240003072    f  W95 Ext'd (LBA)

First partition (primary) STARTS on 2048 and ENDS on 8386559 <- this partition does NOT respect cylinder boundary BUT respects head one.
Of course it contains 8386559+1-2048=8384512 sectors (or 512 bytes blocks).

Second partition (extended) STARTS on 8386560 (i.e. END of previous +1, OK) and ENDS on 488392703 <- this partition does NOT respect cylinder boundary BUT respects head one.
Of course it contains 488392703+1-8386560=480006144 sectors (or 512 bytes blocks).

Since the WHOLE disk is 488395055 sectors there is an unallocated space of 488395055 - 488392703 = 2352 sectors.

2048+8384512+480006144=488392704

255 heads, 63 sectors/track, 30401 cylinders, total 488395055 sectors
488395055-488392704=2351 sectors unallocated.
There must be an error in the above 488395055 as 30401*255*63=488392065

Let's see the contents of the Extended partition (they are what we highly specialized technicians call "a complete mess, a monkey throwing dices would have come out with far more sensible numbers" :w00t:) they simply make NO sense:
/dev/sdb3        20980953   225793574   102406311    b  W95 FAT32
/dev/sdb5         8388608    10502143     1056768    b  W95 FAT32
/dev/sdb6       225793638   488392064   131299213+   b  W95 FAT32
The missing /dev/sd4 is corresponding to an empty EMBR and to the space that Disk management sees as 102.66 Gb.
The first volume inside extended should be one head (63 sectors) after the beginning of the extended, in this case 8386560+63=8386623, BUT you have instead one volume starting at a 2048 offset 8386560+2048=8388608 (this should be /dev/sdb3 and NOT /dev/sdb5).....
IF that partition starts at 8388608 and ends at 10502143 it is 10502143+1-8388608=2,113,536 sectors *512=1,082,130,432 which sounds exactly the size of the "Swap" partition as seen in the disk management.
Since after it we have the "hole" created by the missing /dev/sd4 there is no way to carry n the analysis sequentially.
The "next" partition (the one before last) is /dev/sdb3 which starts at 20980953 and ends at 225793574, 225793574+1-20980953=204,812,622*512=104,864,062,464 which sounds a lot like the "Programs" one.
Last partition is dev/sdb6 that starts at 225793638 and ends at 488392064 (it should start at 225793574+63 but seemingly starts at 225793574+64), 488392064+1-225793638=262,598,427*512=134,450,394,624 which sounds a lot like the "FILES" partition.

First issue is that you used different tools (and Operating Systems ) to fiddle with that partitioning.
NO XP will ever create a partition starting at 2048 (Vista :ph34r: and later may) and any XP will also respect cylinder boundary for End of partition.
Gparted can use any of the above (and it is particularly easy to make confusion as it's interface is FAR from intuitive when it comes to "details" like this one).

The real issue here is that you are risking GREATLY :ph34r:, if you ever use XP disk manager to do a trifling thing such as changing the active status of the primary, to loose volumes in the Extended, see:
http://reboot.pro/to...itioning-issue/

How exactly you managed to "cross-link" the EMBR chain is a mistery, I never saw that happening with "automated" tools like gparted.

It is possible that the obsolete version of Gparted you used "GParted v0.13" right now we are at 0.16 (BUT DO NOT EVEN THINK of using it or 0.15):
http://gparted.sourc...et/download.php
as there are NEW, SERIOUS issues with them.
So, be nice and get 0.14.1-6 instead:
http://sourceforge.n...table/0.14.1-6/

There are no issues in solving that mess but you need to confirm that you are familiar with using a hex editor, the intended procedure is:
  • correct the EMBR chain WITHOUT moving/resizing anything (by manually hexediting entries in the various EMBR's)
  • once the above is done (and verified to be done correctly) use 0.14.1-6 to adjust size and position of the Extended partition and all volumes inside it (this time respecting partition cylinder boundaries)
Though there should be NO issues whatsoever in keeping the primary parittion "as is" , to have an entirely "kosher" partitioning you will also need a PE of some kind (or an alternate XP install or anyway *some* way to edit the Registry "offline") because if we move/resize the primary the already installed Windows XP won't likely boot due to the invalid offset in \DosDevices\

Let me know if you want to proceed and I'll give you instructions.

jaclaz

#5
j7n

j7n

    Member

  • Member
  • PipPip
  • 290 posts
  • Joined 18-December 06
  • OS:XP Pro x86
  • Country: Country Flag
Thank you for your response.

I read the articles about disappearing partitions. So, XP can't work with logical volumes that are not aligned to cylinder. I didn't know about this. I chose the default 1 MB alignment in GParted, because that's supposed to be the new standard format, although it doesn't matter with this old HDD. I thought I'd be prepared to clone the system onto a new drive if needed.

To the compatibility issues between XP and Vista, I can also add that Win98 setup crashed with Stack Fault in SUWIN, if asked to install to a non-cylinder-aligned partition.

Here were the steps I took:

1. Copy Windows 98 files onto the new system partition.
2. Write "msdos" Partition Boot Sector with BOOTICE (shouldn't in theory affect the MBR).
3. Verify that Windows 98 boots correctly. "Swap" receives drive letter F. I did not investigate further why.
4. Install XP onto the same partition as well (without formatting). It may have broken something here while updating the boot record. But it should only write the boot code to the partition as well.
5. "Swap" now receives drive letter E, indicating that something happened during installation and first launch of XP.

Posted Image
(System is a primary partition on the other physical HDD.)

Somehow the volume "Programs" has become the primary partition 3 and overlapping with the extended partition 2, which originally contained it. This explains why there is unallocated space within the extended partition.

I think FDISK considers a "block" to be 1 kB here. I believe that is internal to that Linux system somehow.

So I need to recreate "Programs" back in the extended to unoverlap them. I can use a hex editor. But I don't understand the Extended records.

Attached File  current_mbr.txt   512bytes   2 downloads

Edited by j7n, 30 April 2013 - 12:19 PM.


#6
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,802 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

So, XP can't work with logical volumes that are not aligned to cylinder. I didn't know about this.

Not exactly.
To be fair, there are NO issues whatsoever with XP and non-cilynder aligned partitions, the only issue is with XP's Disk Management.
The thread I pointed you about is evidence that in order to do a very trifling thing (set a single byte in the MBR to either 80 or 00) the tool re-checks/re-calculates/attempts to fix/whatever the EMBR's.
If you NEVER use Disk Management (and probably also the Diskpart for XP) you won't have any issue, additionally it is possible (actually very probable) that among the (few) actions you can carry in XPìs Disk Management, only a subset will cause the corruption.
Still this may be satisfactory enough on (example) dual-boot system with Vista :ph34r: or 7, you only have to remember to use the Disk Manager from the more recent OS, but in a single boot to XP is what I call "asking for troubles".


I chose the default 1 MB alignment in GParted, because that's supposed to be the new standard format, although it doesn't matter with this old HDD. I thought I'd be prepared to clone the system onto a new drive if needed.

Well if you actually "clone" it it will have EXACTLY the SAME issue, there is "clone" and "clone" ;):
http://www.msfn.org/...ocking-station/
http://www.msfn.org/...__1#entry974798


To the compatibility issues between XP and Vista, I can also add that Win98 setup crashed with Stack Fault in SUWIN, if asked to install to a non-cylinder-aligned partition.

That doesn't come "unexpected", but good to know for sure. :thumbup

Here were the steps I took:

1. Copy Windows 98 files onto the new system partition.
2. Write "msdos" Partition Boot Sector with BOOTICE (shouldn't in theory affect the MBR).
3. Verify that Windows 98 boots correctly. "Swap" receives drive letter F. I did not investigate further why.
4. Install XP onto the same partition as well (without formatting). It may have broken something here while updating the boot record. But it should only write the boot code to the partition as well.
5. "Swap" now receives drive letter E, indicating that something happened during installation and first launch of XP.

Not necessarily, "automatic" drive letter assignment is (slightly) different between DOS (and coversely Win9x/Me) and NT based systems.
I haven't checked your particular setup, if you want the info is here:
http://www.msfn.org/...-drive-letters/
http://support.micro.../kb/51978/en-us
http://support.micro...kb/234048/EN-US
most probably the TWO primary partitions are the origin of the drive lettering difference.



Somehow the volume "Programs" has become the primary partition 3 and overlapping with the extended partition 2, which originally contained it. This explains why there is unallocated space within the extended partition.

Naah, the MBR you posted has "correct" data.

I think FDISK considers a "block" to be 1 kB here. I believe that is internal to that Linux system somehow.

Yes, this is very possible, but it's like counting cows :w00t:, counting horns and dividing by two is unneededly more complex ....

So I need to recreate "Programs" back in the extended to unoverlap them. I can use a hex editor.

Not really (in the sense that is "alternative".
There is NO "real" overlapping, only the addresses have been overlapped.

The /sdb1 is primary (and OK, apart the alignment)
<0 sectors in between>
The /sdb2 is the Extended partition (and is OK, apart the alignment)
<64 sectors in between, not compatible with cylinder alignment, should be 63, but OK>
The sdb5 is the first volume inside extended (and is OK, apart the alignment)
<The empty space here is actually empty space>
The /sdb3 is (WRONGLY) a primary but it occupies a valid area of the extended partition
<64 sectors in between, not compatible with cylinder alignment, should be 63, but OK>
The /sdb6 is the last volume in extended (and is OK, apart the alignment)

The issue here is the EMBR chain.
The EMBR of the extended may point directly to the "sdb5" and the EMBR of the "sdb5" may point directly to the "sdb6".
Now if you (after having backed up the "Programs" contents) simply delete the sdb3 entry in the MBR and create a new volume in the extended partition (covering the area of the current sdb3+the "empty space") it is likely that it will be added at the end of the chain (i.e. it will become sdb7 in Linux), I really cannot say if partitioning tools like Gparted re-analyze the volumes in Extended and make a "normal" sequential EMBR chain, as a matter of fact I suspect that the issue was originated *somehow* by a non sequential EMBR chain :unsure:
It is also possible that the current situation is what "throws off" gparted.


I can use a hex editor.

Good.
You should make a copy of:
  • the MBR - 1st sector/LBA0 (which you already did, but please instead of changing file extension compreess all the sectors into a .zip file)
  • LBA 2048 <- not really-really needed, but while you are at it...
  • LBA 8386560 <- EMBR extended
  • LBA 8388608 <- PBR sdb5
  • LBA 10502144 <- (hopefully) EMBR
  • LBA 20980953 <- PBR sdb3
  • LBA 225793574<- EMBR sdb6
  • LBA 225793638<- PBR sdb6
and post the .zip.

jaclaz

#7
j7n

j7n

    Member

  • Member
  • PipPip
  • 290 posts
  • Joined 18-December 06
  • OS:XP Pro x86
  • Country: Country Flag
I read up about Extended Partition on the web and understand the situation now, but still not the step that caused it. But that's ok. I have a "nested" extended partition with unused space. The first sector in extended is pointing to it+1 (that's odd), which contains "swap", and then points directly to "files". I have about 5 GB of unused space between "swap" and "programs" (that may have confused XP setup when it attempted to "activate" its partition).

http://dl.dropboxuse.../st250_lbas.zip

Let me fix this myself. Is it acceptable to edit the partition structure from within running Win98 without it crashing?

Would Disk Management later corrupt the extended partition of an existing disk if I used it to modify a new/another disk? Probably not, in that case I consider it "safe enough".

#8
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,802 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Let me fix this myself. Is it acceptable to edit the partition structure from within running Win98 without it crashing?

Sure, once it is booted, it is booted, of course if you make errors in the editing of the MBR (about the active partition) you may have the system unbootable at next reboot.

Would Disk Management later corrupt the extended partition of an existing disk if I used it to modify a new/another disk? Probably not, in that case I consider it "safe enough".

I don't think so, the issue seemingly only applies to *any* disk that is not cylinder aligned, so if you access/modify a disk which is aligned you are not going to create issues with that disk (whilst the non-aligned one is not accessed at all).
But I find it unneededly risky, once the partitioning is "valid" (but not cylinder aligned) and thus gparted can re-access properly the disk, it would be easy to slightly resize/move the partitions to have them properly aligned.

The theoretical advantage in speed on a fully aligned filesystem (which you don't have anyway for FAT 16 or 32 if you just align the partitions to the cluster multiple), see these:
http://www.msfn.org/...n-its-clusters/
http://reboot.pro/to...-under-windows/
http://reboot.pro/to...-memory-drives/

is only noticeable on very slow devices (USB sticks) and/or in case or really intensive Disk I/O (think of the database server use that initiated it all).

Peeking in the files you posted maybe I found an explanation for why the issue arose (or however something that may be involved in it), it seems like Gparted already made the "sectors before" the "right value" (i.e. absolute offset from start of the disk) instead of the (wrong, but defacto standard) MS way that puts there the offset from the previous EMBR.
Compare with:
http://www.goodells.net/multiboot/
http://www.goodells....ot/ptable.shtml
This may have *somehow* tricked the MS tools in believeing that the partition was primary and deciding to "fix" it.

Do you need assistance for the editing of the EMBR's? (or you want to try by yourself first) :unsure:


jaclaz

#9
j7n

j7n

    Member

  • Member
  • PipPip
  • 290 posts
  • Joined 18-December 06
  • OS:XP Pro x86
  • Country: Country Flag
The problem has been SOLVED by editing the boot sectors. All files are still there, and the Extended partition is now on sector multiple of 63. Elegant solution, and much quicker than booting into Gparted. Posted Image

Disk /dev/sdb: 250.1 GB, 250058268160 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488395055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa129a129

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     8386559     4192256    b  W95 FAT32
/dev/sdb2        20980890   488392063   233705587    f  W95 Ext'd (LBA)
/dev/sdb3         8388608    10502143     1056768    b  W95 FAT32
/dev/sdb5        20980953   225793574   102406311    b  W95 FAT32
/dev/sdb6       225793638   488392064   131299213+   b  W95 FAT32

Partition table entries are not in disk order

Posted Image

Posted Image

Now, after I get the other System out of the way by removing the other disk, I'll get Programs as "D" in all operating systems. Win98 doesn't complain about having more than one primary partition. I wanted the swap file (also shared) out of the way so System can be easily backed up.

The theoretical advantage in speed on a fully aligned filesystem

I'll research that next.

Thank you for pointing me in the right direction. Posted Image

#10
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,802 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Good. :)

While you are at it, you should also solve this (very minor) inconsistency:

Partition table entries are not in disk order

Just swap second and third partition entries in the MBR.

jaclaz

#11
j7n

j7n

    Member

  • Member
  • PipPip
  • 290 posts
  • Joined 18-December 06
  • OS:XP Pro x86
  • Country: Country Flag

The theoretical advantage in speed on a fully aligned filesystem (which you don't have anyway for FAT 16 or 32 if you just align the partitions to the cluster multiple)

It appears that aligning the partition is completely unnecessary for FAT, and the more compatible partition boundaries of 63 sectors can be used instead at no penalty. The aligment seems to always be mod2 with regards to partition start and depends on the exact size of the volume, but can be shifted forward or backwards using the "reserved sectors". I've recreated the file system on System with mkdosfs just to see how it's done, and now I have a 4k aligned partition with reserved sectors 38 instead of the default of 32.

It didn't help that....

mkdosfs can not create bootable filesystems. This isn't as easy as you might think at first glance for various reasons and has been discussed a lot already. mkdosfs simply will not support it

It neglected to write one bit to indicate that the file system is not on a floppy. The floppy drive would buzz, and the boot sector would print "Disk error. Press any key to restart." Where on the whole disk do I have an error!?

To make the partition bootable again, besides boot code, I had to write 0x80 at 40h of the bootsector.

#12
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,802 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

The aligment seems to always be mod2 with regards to partition start and depends on the exact size of the volume, but can be shifted forward or backwards using the "reserved sectors". I've recreated the file system on System with mkdosfs just to see how it's done, and now I have a 4k aligned partition with reserved sectors 38 instead of the default of 32.

Very good. :thumbup

To make the partition bootable again, besides boot code, I had to write 0x80 at 40h of the bootsector.

Yes :) this - strangely enough - is "normal".

Byte 40h is one of the "strange" things, remainder of old versions of DOS, it is "disk number", 00 means "floppy" and 80 means hard disk 128, i.e. first disk (and no matter if the disk is first or second or third, it will anyway remain 80).
It looks a lot like superfluous, as the F8 at 15h should be enough to identify Media Type, and apart from 00 and 80 (with the exception seen below) values like 81 or 82 are never written by "modern" DOSes, so it is more a kind of "switch" floppy/hard disk than an actual "Physical Disk Drive ID" or Disk number"

JFYI:
http://thestarman.pc...mbr/MSWIN41.htm

And, in some FreeDos Version it may become FF or 255 as Auto-detect (but only on FAT12 and 16):
http://www.911cd.net...showtopic=14388

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users