>2TiB external USB drive and WinXP? Of course!

[tekkaman]

16 minutes ago, Dixel said:

What makes you think I didn't understand? You wrote "external". External ones always worked because they were meant to - by using a conversion chip on-board.

 

 

As far as I know even external ones couldn't be read because XP 32 bit couldn't handle partitions bigger than 3TB. Or at least that's what I kept hearing back in 2009 or something.

[Dixel]

3 hours ago, tekkaman said:

As far as I know even external ones couldn't be read because XP 32 bit couldn't handle partitions bigger than 3TB. Or at least that's what I kept hearing back in 2009 or something.

No, wrong, it depends on the year of manufacture. I had dozens of such 4TB drives made by WD, produced somewhere in 2014 - 2015. All worked as intended.

[Dixel]

3 hours ago, tekkaman said:

XP 32 bit couldn't handle partitions bigger than 3TB. Or at least that's what I kept hearing back in 2009 or something.

It's only when you connect the HDD via SATA directly to the Mobo, but it would mean it's NOT external anymore. It's internal.

[jaclaz]

Only to (hopefully) clear the matter.

The 2.2 Tb original limit depends on the 32-bit size of the MBR partition table  that sets at 2^32-1=4,294,967,295 the max number of sectors accessible.[1]

If the disk exposes 512 bytes/sector the limit is then 2.2 Tb.

If the disk exposes 4Kb/sector size (so-called "Native 4k" disks) the limit is 8 times that much.

What a number of USB external enclosures (the controllers in them) do is to expose on the USB connection the disk as if it was a Native 4k one, i.e. it makes the XP believe that the disk has 4 kb/sector, thus allowing to use "normal" 512 bytes/sector disks of much larger sizes than 2.2. Tb.

The chosen method of alignment (to the cylinder up to XP, to the Mb on Vista and later) is unrelated.

jaclaz

[1] only for the record, at the time I devised a partitioning schema with two (or more) partitions that allowed to use MBR disks up to (almost) 4.4 Tb, but (a few) actual tests led to the conclusion that while the schema did work on later OS (7 at least) it did not work on XP due to some other limitation (still 32 bit related) in system files.

 

 

[tekkaman]

1 hour ago, jaclaz said:

Only to (hopefully) clear the matter.

The 2.2 Tb original limit depends on the 32-bit size of the MBR partition table  that sets at 2^32-1=4,294,967,295 the max number of sectors accessible.[1]

If the disk exposes 512 bytes/sector the limit is then 2.2 Tb.

If the disk exposes 4Kb/sector size (so-called "Native 4k" disks) the limit is 8 times that much.

What a number of USB external enclosures (the controllers in them) do is to expose on the USB connection the disk as if it was a Native 4k one, i.e. it makes the XP believe that the disk has 4 kb/sector, thus allowing to use "normal" 512 bytes/sector disks of much larger sizes than 2.2. Tb.

The chosen method of alignment (to the cylinder up to XP, to the Mb on Vista and later) is unrelated.

jaclaz

[1] only for the record, at the time I devised a partitioning schema with two (or more) partitions that allowed to use MBR disks up to (almost) 4.4 Tb, but (a few) actual tests led to the conclusion that while the schema did work on later OS (7 at least) it did not work on XP due to some other limitation (still 32 bit related) in system files.

 

 

I always heard that there was some sort of emulation going on if you partition a native 4K hard drive in XP. And that it would work but at lower performance if it was not correctly aligned. Obviously if you buy an external HDD today it will come correctly aligned and work fine on XP. But if for whatever reason you need to partition the hard drive again you should do it on Windows 7 and then use the drive on XP normally. At first when 4k native alignment was new there were all sorts of software that would check if the drive was correctly aligned. Even HDD manufacturers provided free software for that. All that was done for using the drive on XP. I remember using Acronis from WD just to check if they were correctly aligned. If you partition a 4k drive on XP it won't be correctly aligned and you would lose performance. I just remember reading about that constantly when 4K alignment was new. 

Edited June 13 by tekkaman

[Dixel]

6 hours ago, jaclaz said:

Only to (hopefully) clear the matter.

The 2.2 Tb original limit depends on the 32-bit size of the MBR partition table  that sets at 2^32-1=4,294,967,295 the max number of sectors accessible.[1]

If the disk exposes 512 bytes/sector the limit is then 2.2 Tb.

If the disk exposes 4Kb/sector size (so-called "Native 4k" disks) the limit is 8 times that much.

What a number of USB external enclosures (the controllers in them) do is to expose on the USB connection the disk as if it was a Native 4k one, i.e. it makes the XP believe that the disk has 4 kb/sector, thus allowing to use "normal" 512 bytes/sector disks of much larger sizes than 2.2. Tb.

The chosen method of alignment (to the cylinder up to XP, to the Mb on Vista and later) is unrelated.

jaclaz

[1] only for the record, at the time I devised a partitioning schema with two (or more) partitions that allowed to use MBR disks up to (almost) 4.4 Tb, but (a few) actual tests led to the conclusion that while the schema did work on later OS (7 at least) it did not work on XP due to some other limitation (still 32 bit related) in system files.

 

 

jaclaz, you're absolutely right, no doubt. The problem is - that person originally wrote about external HDD in boxes, which are (and you know it perfectly fine) absolutely different matter due to the onboard chip that emulates sectors for XP, just like again we  explained. We probably need to pin it up to avoid further confusing posts like from that person. Related matter is, starting somewhere in 2017(?) they ceased to make such external boxes, the disk and its contents is fully visible when connected via SATA directly to a Vista machine, but not visible in XP anymore, of course. XP suggests to format it.

[jaclaz]

@tekkaman

JFYI, the advantages of aligning (one way or the other) is (largely) bul*****.

If "everything" is aligned (NTFS is inherently aligned, FAT 16/32 are usually not) then there some (slight) advantages, actually only noticeable on slow bus or slow devices (such as USB 2.0 devices) on a relatively fast bus (like SATA 3) they are negligible (for traditional rotating hard disks, which also tend to have largish caches) while it is a very good idea to align to multiple of the sector AND of the memory page for SSD's.

Check:

http://reboot.pro/index.php?showtopic=9897&p=85960

https://msfn.org/board/topic/154633-partition-boundary-alignment-in-4096-byte-physical-sector-drives/

 

jaclaz

 

[user57]

we know the request (IOCTL_STORAGE_QUERY_PROPERTY)

that fills up a structure called STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR

and that one has BytesPerPhysicalSector

even if XP dont have this it would be easy to implement this 

the xbox guys write something about FILE_FLAG_NO_BUFFERING is not working, the microsoft website isnt clear about this but (cache). it dont work without a buffer lets say the disc is 2 mb/s fast it actually has to use a buffer because it cant write the entire buffer in 1 step (what is probaly bigger then 2mb), also it needs a buffer that is being processed or it would not know what data to write 

rather it sounds to me that this cache means a internal system cache and the other use a cache from the exe/module itself (therefore the xbox guys rewrite dont work for this flag - but they can do it it should not be hard)

then microsoft write this: "optional file offset in the OVERLAPPED structure, if specified, must be for a number of bytes that is an integer multiple of the volume sector size. For example, if the sector size is 512 bytes, an application can request reads and writes of 512, 1,024, 1,536, or 2,048 bytes, but not of 335, 981, or 7,171 bytes."

but there is no such name in the overlapped structure - weird, maybe they should clarify what exactly in the OVERLAPPEND structure is meant

 

but whatever it dont sounds hard to me either to set the query 4/8 times 512 byte sectors and the oposite way, to write a c++ routine that do something like this is very simple 

and lets say XP has this function/offset/structure/structure-entry it might can use it if not we can add the query function either in kernel or userlevel 

its going like this : deviceiocontrol -> nt/zwdeviceiocontrol -> transfered into IRP

that request is then send to the disc/hdd/ssd whatsoever 

512 * 8 = classical 4096 , that result in 16 TB 

but why not even bigger sectors ? 24 TB is the biggest "normal" harddrive at the moment (to make some examples: the seagate exos x - x24 24 TB, WD red pro 24TB, seagte skyhawk ai+rescue 24 TB)

and already 8 TB is a good value to work with - its usally enough storage (often you have enough with discspace with 1 TB, for rather normal work)

Edited August 31 by user57