Jump to content

Read GPT hard disk on Windows XP


Cixert

Recommended Posts

What I recommend to try - perform "4K alignment" it's known to help XP in some cases.

Since Windows XP doesn't support 512e .

The procedure was popular some decades ago.

https://www.minitool.com/lib/4k-alignment.html

"Although 512e solves the compatibility problem and it doesn’t force complicated changes in computing system, it still has some defects. Actually, the translation process of 512e sacrifices its performance to a certain extent, especially in writing performance.

When you write a data that is neither a multiple of 4K nor aligned to a 4K boundary (4K misalignment, click 4K alignment to know more), a operation known as read-modify-write (RMW) is performed, which can result in a perceptible impact on writing performance to users."

Source:

https://www.partitionwizard.com/help/what-is-advanced-format.html

 
Link to comment
Share on other sites


Sure, if an authoritative source like that doesn't mention XP it won't work with them.

The whole point is that the translation happens in the hard disk controller, the older OS's will only see 512 bytes sectors, some newer ones may be able to also see the underlying 4096 bytes ones (but they will anyway use the logical 512 bytes ones).

The whole stuff was developed to maintain compatibility with older OS's and with BIOS (that actually *needs* the 512 bytes sectors to boot form a disk).

XP can anyway access 4K sectors (but won't ever boot from one of them), very likely 2000 cannot.

We have the working experience (thanks to Dave-H's abillties in choosing the most incompatible hardware existing) about a "queer" hard disk (and its external enclosure) that exposed 512 or 4K depending on the interface and at the time we put together a workaround, JFYI:

https://msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/

https://msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/

Anyway the clarification only about the term "cluster" that only appllies to file systems and their structure, not to the disks.

jaclaz

 

PS: only as a reminder, a "new alignment" partitioning scheme has very high probabilities of being corrupted by Disk Manager of XP (not the primary partitions, but the logical volumes inside extended).

As long as you NEVER use the XP Disk Manager on that disk there are no issues:

https://msfn.org/board/topic/176917-help-i-aligned-my-partitions-and-now-the-pc-wont-boot/

 

 

Edited by jaclaz
Link to comment
Share on other sites

2 hours ago, jaclaz said:

We have the working experience (thanks to Dave-H's abillties in choosing the most incompatible hardware existing) about a "queer" hard disk (and its external enclosure) that exposed 512 or 4K depending on the interface and at the time we put together a workaround, JFYI:

https://msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/

https://msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/

I don't do it deliberately, honest!
:D

I looked at the two Asmedia cards' readouts when booting.
The card with eSATA sockets, which works with the 3TB disk, but has horrendous errors with the other two I tried, says it's version 0.95.
The one without eSATA sockets, which was sent to me first in error, and does not have the controller errors, says it's version 4.30.
Other than that, the readouts are identical, they both say that they are Asmedia 106x SATA Controllers in AHCI mode.

So, that could be the answer, the one which works has an apparently much later firmware version on it.

Of course, both cards produce much the same serious NTFS filesystem corruption when going between Windows XP and Windows 10.
:no:

@Andalu said this configuration works fine for him, but presumably his system is single boot.
It may be that this configuration just doesn't work in a dual boot system, due to some difference in the way that XP and 10 write files to GPT disks.
I really don't know why that would be, but I'm not sure at all now whether it's fixable.
:(

Link to comment
Share on other sites

Something else I noticed and forgot to mention, in case it's relevant.
When I look at the 'safely remove hardware' window in XP with the 3TB disk mounted, I see this.

Clipboard-2.thumb.jpg.d84159d267d06172f6b96adb351ee888.jpg

Why are there two 'generic volumes' listed?
With the other disks I tested, there was only one.
:dubbio:

Link to comment
Share on other sites

I always start checking any hardware by disconnecting everything, only that part needs to be left. I also played with flashing many times before, even changing GPU BIOS with the same specs can improve performance.

For example, I had and old EVGA GTX 980 (2014 or 2013), it had a conflict with my 192Khz PCI audio board, I re-flashed the GPU - problems gone. I took the default nVidia reference BIOS.

I guess it's just more tested and compatible rather than "partner" manufacturers' BIOS. And yes, I too have a very similar Xeon Mobo.

Link to comment
Share on other sites

Hi  @Dave-H

unfortunately, for the past few days I have been experiencing problems with corrupted files and unreadable folders even on my GPT disks connected to the asmedia card in XP.

After reading about the problems you reported in your posts I did a check and realized that for example some video files were no longer playable in both XP and Win10.

The strange thing is that in both operating systems, checking with chkdsk via command prompt never detected any anomalies.

Since discovering such issues, I have done some tests to try to figure out what they might depend on and at the moment I can say that probably in XP the problem is exceeding the "classic" 2.2TB limit. Today, in a 4TB disk, after verifying that all files occupying a space of 2,198,497,806,087 bytes were without problems, I copied others to it until 2,473,491,444,978 bytes were reached: no problems detected in copying and no problems for both old and new files but only until the next reboot of XP when some old files previously working were now corrupted.

 

I will have to do more tests to be sure of the above and also to be able to figure out whether the anomalies found may depend on the asmedia card and its driver or firmware versions or the disk.sys and partmgr.sys drivers that cannot work in XP as they do in Win2003 (where I did not detect any problem even exceeding the 2.2TB limit) or other reasons that at the moment I cannot imagine what they may be.

 

I will report the news as soon as I have definite information about it.

First, I will have to find time to make a new backup of the files that then became corrupt :(

 

Link to comment
Share on other sites

Thanks @Andalu!

Before we were so rudely interrupted, I was about to post that I've really given up on this now.
I've bought two 2TB disks, and I'm going to use those for my backups, in two enclosures which I can easily swap over.

Using a 3TB disk is just not stable or reliable enough to use on my multi-boot system.
As we're talking about backups, obviously anything which might make the data on the disks unusable is a complete no-no.

I don't think it's anything to do with the workarounds for handling GPT disks on XP.
The problem is exactly the same whether using the Paragon driver or using the files from Server 2003.

The errors are there even when the disk is connected directly to the motherboard, not via the SATA card.
So, I don't think that they can be being caused by working through the card interface.

As you are apparently seeing similar issues, I think it's just something to do with the way that XP interacts with disks over 2TB, which even the driver change does not seem to fix.
It is apparently working correctly in XP, but generating a file structure which is actually corrupt, which is quickly revealed if you then try to use the disk on Windows 10.
Likewise, a transfer done using Windows 10 is seen as corrupt on Windows XP.

I really don't know whether that is resolvable.
:(

Link to comment
Share on other sites

@jaclaz @Andalu

Back again!
I've now abandoned trying to use the 3TB disk with XP.
If you ever get to the bottom of what was happening there @Andalu I would be very grateful to know!

I'm now using a 2TB disk again, which is fine of course.
I'm still getting the annoying problem of the driver installation dialogue popping up when I mount the disk though, and it telling me that the driver isn't signed.
As I found before, I don't seem to be able to override this warning, and I've done some further investigation on this.

It now seems that almost every driver file on my system says it's unsigned if I look at the file details in Device Manager.
This includes the Microsoft driver files using original system files, which should be signed of course.

I've now started a new thread about this problem.
:yes:

Link to comment
Share on other sites

@Dave-H

No good news from here. I tested a new 4 TB GPT disk extracted from a Seagate Expansion enclosure by connecting it to an internal sata port and starting copying files in successive stages in both Win10 and Win2003 until it reached 2,050,490,049,862 bytes and then exceeding this limit by copying more files until it reached 2,459,394,870,229 bytes.

In Win2003 I checked every file at the end of each copying step (both those just copied and those already copied in the previous steps) without ever encountering any problem of corrupted files, even when I chose to install the asmedia v2.0.3.1 driver for the intel sata controller. Up to this point, the disk has never been connected to an XP system.

Unfortunately, in XP, with the same version of the Win2003 drivers, I did not get the same result: as soon as the GPT disk with the files reaching a total of 2,459,394,870,229 bytes was connected to the internal sata port of the intel controller (for which the same version of the asmedia driver had been installed), without having copied or deleted anything on it, I immediately found that some files were corrupt: their size was identical to that of the original files but the content was different. The total number of corrupted files (all belonging to the folders of recently copied files) was 264,190,679,758 bytes so subtracting it from the cumulative total of all the files (2,459,394,870,229 bytes) gives a result of 2,195,204,190,471 which is very close to the maximum limit of an MBR disk (2,199,023,255,552 bytes)*.

But isn't it about a GPT disk? :dubbio:

 

Edit: * with a sector size of 512 bytes.

Edited by Andalu
Link to comment
Share on other sites

2 hours ago, Andalu said:

Unfortunately, in XP, with the same version of the Win2003 drivers, I did not get the same result: as soon as the GPT disk with the files reaching a total of 2,459,394,870,229 bytes was connected to the internal sata port of the intel controller (for which the same version of the asmedia driver had been installed), without having copied or deleted anything on it, I immediately found that some files were corrupt:

Are you guys formatting the 2TB+ drive in XP? or somewhere else and then using it in XP?  The only way I would begin to trust the drive is if you can format it in XP's Disk Management and it shows as the correct size.  Then copy one large file over, hash check, then copy 2TB+ and see if it first file gets corrupted.  If Disk Managment can't format the proper size, then I would assume it will not work correctly even if you are able to see "correct" size when formatted with something else.

Link to comment
Share on other sites

Years ago, I had XP64sp1 on a old computer in IDE mode.  I added a 4TB drive that i formatted with parted gparted.  It showed as 4TB in XP64 disk managment, but as I copied over past the 2TB mark, files started getting corrupted.  Trying to format the drive in Disk Management only showed as 1.something TB.  XP64 should have been able to handle large GPT data drives, but I guess maybe it needed to have a newer service pack version or AHCI to do it properly.  I didn't bother to investigate.

Recently I tested 4TB on XP64 updated to 2019, and it was able to format it and show the correct size.  Did the overwrite testing and worked fine with the win7 amd sata and the win8 ahci drivers backported.

Same test with server 2003x86 R2.  I didn't test overwrite, but it was able to format and see correct size just like XP64 (aka server2003x64) so I assumed it was fine.

With XP32 updated to 2019, using the disk.sys and partmgr.sys from 2003, along with same win7 amd sata and win8 ahci drivers. When trying to format it with Disk Management it would do the same 1.something TB size, so not able to handle 2TB+ drives.  When I plugged in the 4TB drive formatted with gparted, either internally or with a USB3 capable external enclosure, it did not show up as a readable disk in Disk Managment.  I didn't test, but I would think it would be safe from corruption since it wasn't seen.  But would need to confirm with hash of files before trusting it.  When I tried a very old enclosure, it did show up as 4TB, but that is misleading and I knew it would start corrupting since the USB-SATA chipset itself was limited to 2TB.

 

Over at mdl I made a small post with other files I tried to copy over from 2003 to see if I could get past the 2TB limit, but I guess it's probably more involved than just simply copying over two files needed to get GPT <2TB to work on XP.  I also tried paragonGPT, but didnt work for me.  From comments on the paragon patch posts over on hardwarefetish it seems that it's meant to work with IDE and not with AHCI drivers.

 

Link to comment
Share on other sites

I didn't format my 3TB disk at all, it was already formatted when I bought it, and I just used it as it was.
It never actually had more than 2TB of data on it.
:)

Link to comment
Share on other sites

@pappyN4

Hi,

thanks for the advice, but formatting the GPT disk in XP -> Disk Management did not work: even in this case, the first file copied on the disk immediately became corrupted as soon as the 2.2 TB limit was reached.

But unlike what happened in my previous tests performed on a GPT disk initialized by the manufacturer and with other disks initialized by me in Win10, after completing the copy operations and rebooting the system, connecting the disk to the same internal sata port, all the files are now disappeared. As can be seen from the following image, the disk is now seen as both GPT and MBR and also all operations that should be allowed on the partition are now greyed out:

GPT-MBR.png

The same happens by plugging the disk in Win10.

For the other GPT disks tested previously, however, files under the 2.2TB limit still remained visible and fully available in XP.


At the moment the possibility of using a GPT disk greater than 2TB in XP seems to be impossible to achieve :(

The only way to be able to use a disk larger than 2TB remains to initialize the drive in MBR style by using the WD Quick Formatter utility, even if only for the external drives.

Link to comment
Share on other sites

1 hour ago, Andalu said:

@pappyN4

Hi,

thanks for the advice, but formatting the GPT disk in XP -> Disk Management did not work: even in this case, the first file copied on the disk immediately became corrupted as soon as the 2.2 TB limit was reached.

GPT-MBR.png

 

I'm assuming when you formatted it with XP it was an incorrect 1.6TB size?  I was never able to get XP to format to it's correct 4TB, so it always ended up being corrupted one way or another. :(

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...