Windows 10 Diskpart seems confused as to disk size - but only sometimes

[Jaap Verhage]

Hello everyone,

I've come across a weird problem that I'd like to share with you: under certain circumstances, Diskpart and some other programs don't report the correct capacity of a hard disk.

The disk in question is a new 4 TB, or 3.64 TiB (3726 GiB), Seagate BarraCuda, initalized as a GPT disk with one partition, covering the whole of the disk. I'm using it as a data disk, D:, in an Optiplex 330 PC, running 32-bits Windows 10-1830.

What happens when I boot the PC normally, is that Diskpart reports a disk size of 1678 GiB, containing one partition of 3726 GiB. Come again? Yes, that's right: the partition is more than twice the size of the disk it's on. Two partition manipulating programs, Minitool Partition Wizard and AOMei Partition Assistant, both see the disk as having a size of 1678 GiB, and one partition of the same size. So they partly agree with Diskpart. Minitool as well as AOMei report way too few cylinders and physical sectors, which might explain where they get their sizes from - or the other way around. The number of cylinders reported is 219051, whereas it shoud be 486401; the mumber of physical sectors reported is 3519069872, which should be 7814037168.
However, Disk Management, Chkdsk and Explorer all agree that the disk and its partition are 3726 GiB.

It gets stranger. If I boot the Optiplex with a Win 10-1709 recovery USB, made on the Optiplex some time ago, all programs agree that the disk and its partition have a size of 3726 GiB, with the correct number of cylinders and physical sectors. If I connect the disk to a USB port of the Optiplex or another PC via a docking station, I get the same results. If I put the disk in another PC as drive D: , all programs agree as well: 3726 GiB, nothing wrong.

So what is going on here? Nothing seems wrong with the disk or with the Optiplex's SATA controller, as the disk is read correctly when booting with a recovery USB. It's as if there is some wrong information floating around in a hidden corner of Windows, which rears its ugly head whenever the disk in question is hooked up.

Maybe it's nothing, but I don't like discrepancies like these - they make me distrust my hardware. It's like there's a ticking time bomb that can go off any minute, making the disk unreadable. So I'd like to correct it! What I've already tried, is:
- wiping the disk clean with Diskpart and re-partitioning it;
- cloning the disk (sector-by-sector copy) from a known good identical twin in a docking station.
Neither attempt had any effect, which strengthens my idea that it's not the disk that's at fault here. But then, what is? And how do I put things right?

Any ideas on how to go about this will be greatly appreciated.

Regards, Jaap.

 

[Neemobeer]

The only way you would get a 32 bit Windows 10 is if you upgraded Windows 7 or 8 that was also 32 bit. There is a limited disk size of 2.2TB I believe. You'll need to download and install Windows 10 64 bit.

 

[Jaap Verhage]

Hello Neemobeer,

thanks for replying. I indeed updated a 32-bit Windows 7 installation. However, nowhere have I come across this 2.2 TB disk size limitation that you mention. Can you point me to its soiurce?

Regards, Jaap.

 

[Neemobeer]

I read the article wrong. So 2.2TB is the limit on an MBR partition scheme. GPT can go in the exabytes, but there is an OS limit set in different versions of Windows. The other important information is that on older computer that doesn't support UEFI such as your system, they can't boot from an EFI partitioned system, so your drive may not actually be GPT.

In diskpar you can type
list disk if there is a * under GPT then it's GPT, if not its MBR

You can then type list vol to see all defined volumes and

select disk # then list part to see partitions on that disk.

 

[Jaap Verhage]

I read the article wrong. So 2.2TB is the limit on an MBR partition scheme. GPT can go in the exabytes, but there is an OS limit set in different versions of Windows. The other important information is that on older computer that doesn't support UEFI such as your system, they can't boot from an EFI partitioned system, so your drive may not actually be GPT.

In diskpar you can type
list disk if there is a * under GPT then it's GPT, if not its MBR

You can then type list vol to see all defined volumes and

select disk # then list part to see partitions on that disk.

Hello again, Neemobeer. The disk in question is GPT, and I'm not booting from it, it's a data disk, as I wrote in my post.
Yesterday I booted from a Win 10-1709 recovery USB, checked the disk was seen as 3726 GiB by Diskpart (it was), cleaned the disk with Diskpart and partitioned it again, then formatted it from Diskpart, not quick but slow, hoping that would make a difference. After some 7.5 hours this was done. The result is that, after booting normally, the disk is again seen as it is (3726 GiB) by disk management, chkdsk and explorer, and as being 1,64 TiB by Diskpart, AOMei Partition Assistant and Minitool Partition Wizard, just as I wrote in my orginal post. When copying data to it, way too early (somewhere around that 1.64 TiB mark?), the copying stops, presumably because the disk appears to be full. I'm totally baffled.

You write about GPT partitions: "there is an OS limit set in different versions of Windows". Can you point me to the source of that information? I can't find it, at least not for Windows 10.

Regards, Jaap.

 

[Neemobeer]

It should be somewhere around 16TB on Windows 10 home. They should be set, but I would verify your cluster size is at 4096.

From an elevated command prompt fsutil fsinfo ntfsinfo C: replace C: with your drive letter.

 

[Jaap Verhage]

It should be somewhere around 16TB on Windows 10 home. They should be set, but I would verify your cluster size is at 4096.

From an elevated command prompt fsutil fsinfo ntfsinfo C: replace C: with your drive letter.

Hello Neemobeer,

thanks for holding on. I run Windows 10 Education (kind of Pro Plus ), and my cluster size is 4096 bytes. However, I noticed something strange in the outpout of the fsutil command. When the problem disk is in a docking station, fsutil says there are 512 bytes per physical sector. When it's in the PC where it belongs, fsutil says the same thing. But when I connect it to the SATA controller of a more modern PC running 64-bit Windows 10, according to fsutil the disk has 4096 bytes per physical sector. This last figure is as it should be, as it's a modern disk, only a couple of weeks old. It's getting curiouser and curiouser...

As for your remark "It should be somewhere around 16TB on Windows 10 home", can you point me to the source of that?

Regards, Jaap.

 

[Jaap Verhage]

Well, it seems my problem is solved (or has gone away ). I had been playing with the idea of updating rthe Windows on the PC in question from 32 bits to 64 bits for some time, but the prospect of performing a clean install and then re-installing everything all over again kept me from it. But yesterday or the day before I decided to take the plunge. I decided to try and change Windows' language as well, although I had read somewhere that my current licence wouldn't allow that. But lo and behold: it did! So I now have an antique Dell Optiplex 330 with 64-bit Windows 10-1803, in US-English instead of Dutch with some stupid translations, AND... all and sundry programs now agree that I have a D:-drive of 3726 GiB capacity. Yes! So Neemobeers first suggestion turned out to be the right one (thank you Neemobeer! ), although I don't understand why. As far as I know, there are no disk space limitations for 32-bit Windows as compared to 64-bit Windows. Better drivers in the 64-bit version maybe? Anyway, the disk is now seen correctly and the PC is slowly returning to a semblance of the way it looked before the upgrade. All's well that ends well...