2 TiB limit size in MBR hard drives

[rloew]

Quote

 

Yes I was thinking something different when you stated that.  LBA64 will be supported by an existing OS if MS or a 3rd party chose to make a patch like yourself.  But shouldn't LBA64 still work fine with all OSs except they would operate at LBA-48 (with existing patches) or at LBA-28 unpatched?

 

 

 

The Drive would work but you would not have access above the respective limits.

Quote

 

In my opinion this is the future and the GPT Loader to include 2K / XP 32-bit would see more users than DOS/9X/ME combined.

 

 

 

There are more XP users so that is a given. That is why I was looking into extending the EMBR to XP.

Quote

 

Are you talking about the EMBR drives here?  This was where the concern was if someone used your EMBR on some large drive and went somewhere where the destination system was a standard unlicensed non EMBR system how could they access that data?  Even any GPT capable OS and higher shouldn't understand your EMBR scheme even though they are newer than XP unless I'm missing something here?

Is your EMBR scheme somehow compatible and readable/writeable by GPT capable OSs?  Don't you have to patch each OS that the user intends to read / write the data on the EMBR drive?  If someone bought your EMBR user license and they were originally using 95, and they recently bought a W10 installed machine could they read the EMBR drive and if not are you offering all OSs DOS->W10 EMBR drivers and does that user have to bought an EMBR license for each OS they plan on using or does their license cover all OSs DOS->W10 for that one EMBR license purchase?

 

You are missing something. I was referring to EMBR + GPT Drives. GPT capable OSes would use  the GPT. DOS and Windows 9x users would need my EMBR Patches.
The EMBR License is per machine. Any combination of supported OSes are allowed. Currently only DOS and Windows 9x support it.

 

Quote

 

Well maybe you can state what Blu-ray compatible software player you are using on 9X because the only ones that were made were only for XP and later.  Are you reading the original Blu-ray movie disc inside your Blu-ray optical drive?  And what about HDCP and AACS?

 

I never said that there was a player. I said special software would be needed. The existing FileSystem is not used.

Quote

The only way I can think of that could play any Blu-ray only as a video file if it were decrypted first and using a standard video player that could read the format.

Yes. My point was that I can do that with a Video that is longer than 4GiB.

Quote

 

But have you found a way to add HDCP or get an HDMI video card to work in 9X/ME?  If so what video card as far as I know none existed that had 9X/ME drivers.

 

No idea. I used a standard 1080 Monitor.

Quote

 

Can you elaborate on this XP Large File Support for FAT32?  I recall you patched your FAT32 to allow over 4GB file sizes but does every OS the user intends to use need to use your patch first in order to "read" the drive (not write) to it.  When moving such a FAT32 partition that has over 4GB file sizes can Vista or later read these FAT32 over 4GB file sizes or does do you have to patch the Vista OS or later to understand it?  For example will Vista read only the first 4GB-1 and just stop there?  What happens when you write to a FAT32 partition that you've allowed > 4GB file sizes?  Does it corrupt the partition because Vista doesn't understand it or can Vista write over the 4GB file sizes on FAT32 without needing a special driver patch from you?

 

The Patch is an User Mode Overlay. If you look at the Drive under an unpatched OS, you will see multiple files of less than 4GiB. You can corrupt the files by writing to them directly but you won't corrupt the
Partition. You could use splitting and merging programs to access the data if necessary.

 

Quote

What kind of problems are you referring to for 64KB adapters?  Let's assume WD, Seagate, Hitachi have released 64KB sector drives and abandoned all 4KB sector drives.  Now we have 64KB -> 512 Byte adapters.  Explain why these wouldn't work with XP 32-bit or later OS with the MBR scheme.  If all the OS sees everything as 512 Bytes I don't see why this would cause any issue with any OS the same with the 4KB -> 512 Byte adapters are already doing with 4KB sector drives.

Internally Windows 9x uses 4K blocks so adding 4K support was practical. 64K would not work. DOS cannot handle 64K Sectors. It can support 32K Sectors but the performance is very poor.
I would think similar issues would be present in other OSes. I seriously doubt that 64K Logical Sector Drives will be mainstream for a very long time. 64K Physical Sectors maybe.
Pushing the MBR limit in this manner would not be worth it.

Quote

 

Now this might be useful but you still have to prepatch every OS before an existing (4KB->512 Byte) USB drive could be read directly connected to the SATA controller.

 

No free lunch.

Quote

 

If you already own several 4TB USB drives that use the (4KB->512 Byte) adapter do you know enough about BIOS modding to add this code directly to detect the drive so that any SATA controllers can natively interact with them (making them OS patch free)?

 

 

 

I have Patched BIOSes to support LBA-48, but that is a one-off approach. Every BIOS Version would have to be analyzed and Patched individually.

It would still not make DOS or Windows 9x Patch free. Without a specific convention like I use with another aspect of my EMBR, the BIOS would not know what Sector Size to Emulate.
NT OSes don't use the BIOS except for the earliest part of Booting so it would not see any BIOS translator and would still try to use 512 Byte Sectors.

Quote

 

When studying how the original (4K->512 Byte) adapter vs the scheme you came up with did you find any differences in the way they interacted with the drive.  If you've been writing tons of data using this adapter and the user would then try your SectorMapper to read/write to the SATA drive directly not using the 4K->512 Byte adapter will there be any chance of corruption or misalignment?

The only way I can see using a software version of this adapter if it operates exactly the same in code as the hardware.  Otherwise you'd have to use your own SectorMapper from the beginning on an empty drive.  And what happens if you filled the 18TB of information using your SectorMapper then decided to connect this to the 4K-512 Byte adaptor via USB.  Any chance the using the adapter would be slightly different and possibly corrupt the data on it when writing on this drive?

 

They behave the same. As long as the Sector Mapper is used properly, you won't get corruption.

Quote

 

Bottom line:  Would flip flopping using your SectorMapping to write the data and then repurposing it back to the USB enclosure with the 4KB->512 Byte continuously on a constant daily basis have any deleterious effect you haven't anticipated?

 

Not that I know of. How do you expect me to describe something I haven't anticipated?

 

Quote

 

Would you go as far as trusting it enough that if your own family's life were on the line that there's no chance a single bit of data would be corrupted?

 

First, read the terms of my License agreement.

Second, familiarize yourself on the subject of Cosmic Ray upsets.

Edited October 22, 2017 by rloew
Response to added material.

[Yellow Horror]

7 hours ago, jaclaz said:

the point (at least mine) was that there is no need to have GPT to access up to nearly 4.4 Tb on a single hard disk, divided in at least two volumes, this approach has been tested and it works on Windows 7 32 bit successfully.

And, as i read in this discussion before, the trick don't work under XP. And the symptoms suggested that there is a bit capacity limitation somewhere in the XP MBR-to-LBA translating routine. There may be a workaround in patching some XP files, integrating WS03 or 7 files into XP, or develop a replacement routine from scratch. But, IMHO, all this don't worth the efforts (first two solutions are against MS license though). In any case you can't utilise over than 4 Tb drive this way, so comparing with working GPT implementation for XP (Paragon or any alternative) it seems a palliative.

What interested me is:

1. If Paragon GPT loader is compatible with MS "dynamic" drives?

2. If it is compatible with Windows software RAID 5 support (that is disabled in XP by default) precisely?

Quick search give me some clues that the answer is probably "no". It is sad, but may be i am wrong? Can you check if a GPT drive (with Paragon GPTL installed of course) may be converted to "dynamic" under XP?

Edited October 22, 2017 by Yellow Horror

[98SE]

On 10/21/2017 at 1:01 AM, jaclaz said:

@98SE

As long as an image file is within the 4GB (-1 byte) FAT32 file size limit it can of course reside on a FAT32 volume.

There is no actual need to "reverse engineer" a GPT implementation, the way it works is known, it has official public specifications in the UEFI documentation (consisting in more than 2000 - that is two thousand - pages)  it is writing a replacement (or - as seemingly Paragon did - "parallel" driver) for Partmgr.sys that is the problem.

Scroll down the given page on multibooters, the whole point is that MS call "System" what you (and all the rest of the world) call "boot" and "Boot" what you (and all the rest of the world) would call "system".

 JFYI, those duplicated systems are "copies", not "clones" (as always trying to use same naming conventions).

If the 2000 pages are available for GPT then why was Paragon unable to say extend support to 2K or add external USB GPT drives to be readable/writeable?  It seems like a half baked GPT Loader.  That would be the first obvious use for it.  No one really needs a 32TB GPT internal drive and I think you would agree even a 128GB internal drive is more than enough for a Primary MBR Boot device and GPT isn't really necessary to be bootable.  I still see GPT at least from 32TB onward or possibly > 18TB onward if 4K->512 Byte translation adapters have maxed out and GPT to be the forward compatible choice.

Quote

Scroll down the given page on multibooters, the whole point is that MS call "System" what you (and all the rest of the world) call "boot" and "Boot" what you (and all the rest of the world) would call "system".

 JFYI, those duplicated systems are "copies", not "clones" (as always trying to use same naming conventions).

Yes I agree with the Clone = "byte by byte" or "bit by bit" or "nibble by nibble" sorry Apple Talk.

But imaging would not be a clone but can restore it to appear identical to a clone?

For example when you image a partition, let's say you only are using 2MB of data of the 2GB partition.

When you restore back the image it should be byte for byte identical to the original partition.  The image would probably not store the unused/blank data on a new drive as it would be unnecessary.

 

However if say there was left over unwiped data on a "used" drive a "clone" would also retain those "hidden" bits which a data forensic might find useful for clues.  But for the layman this wouldn't be important and any real true "cloning" of empty non relevant data would be a complete waste of space.  But one that detects the "blank/empty/unused areas" for example if a 128GB brand new drive had been Zeroed out and then added a 98SE DOS boot a clone would see the first 1MB and then properly store that data onward that "0"s were filled from 1MB+ to 128GB saving a ton of space.

Curiously what would be the best partition and drive cloner that would do what I just stated?  If I wanted map my drive or analyze how the data was stored and had no idea what kind of drive it was what would be the best program to probe it?

 

The last paragraph that you had previously linked

Quote

You say Tomato

Microsoft calls the partition with the boot files the System partition, and the partition with the operating system the Boot partition. Everyone else refers to them exactly the other way round. The boot files on the boot partition. The operating system on the system partition.

Microsoft "System Partition" = partition "with the boot files".

Microsoft "Boot Partition" = partition "with the operating system"

 

I think you have me reversed because I didn't agree with this which was Microsoft's definition.  Or is my definition somehow a hybrid of the two because I have my Windows Boot Loader separated from the System Partition?

 

I call the C: Boot Partition = the Boot Files (IO.SYS, MSDOS.SYS) for example in DOS.

now the 98SE main operating system files can be put on D:

XP on E:

 

In this case D: and E: according to my definition are "System Partitions" or "Operating System" partitions.

The C: still contains the 98SE DOS and the Windows Boot Loader (2K/XP/Vista/W7/W10) that redirects to the correct "Operating System" partition to continue the OS booting process.  The C: doesn't contain the actual 2K, XP or later Operating System files because those still are on the "Operating System" partition D: or E: where respectively the "Operating System" files of the corresponding OSs are stored.

 

Have I confused you further?

 

Po-Tay-Toe, Po-Taw-Toe

Let's call the whole thing off.

 

Edited October 22, 2017 by 98SE

[cdob]

On 21.10.2017 at 10:28 PM, 98SE said:

I happen to have a 3TB USB bridge adapted drive available ... run some tests

Does the USB bridge offers 512 byte or  4 k sectors?
Which MBR partition data are available out of the box?
Backup the first several sectors.

In case of 512 byte sectors:
Can you try a 3TB floppy? Hence no MBR (sorry for of topic), a partition sector only.
usbstor.sys reads this. XP should work with the 3TB USB drive. No idea about 2000.

Can you use a live linux DVD?
https://wiki.archlinux.org/index.php/NTFS-3G
mkfs.ntfs --force -Q -L "3TB_floppy" /dev/sdX

[dencorso]

6 hours ago, cdob said:

 XP should work with the 3TB USB drive. No idea about 2000.

It actually does work! See:  Confirmed - 3TB HDD USB Drive on WinXP 32bit.  

6 hours ago, cdob said:

Does the USB bridge offers 512 byte or  4 k sectors?
Which MBR partition data are available out of the box?
Backup the first several sectors.

4KiB sectors. The relevant MBR part is decoded below. A full binary image is get attached to the original post.

 

[98SE]

10 hours ago, cdob said:

Does the USB bridge offers 512 byte or  4 k sectors?
Which MBR partition data are available out of the box?
Backup the first several sectors.

In case of 512 byte sectors:
Can you try a 3TB floppy? Hence no MBR (sorry for of topic), a partition sector only.
usbstor.sys reads this. XP should work with the 3TB USB drive. No idea about 2000.

Can you use a live linux DVD?
https://wiki.archlinux.org/index.php/NTFS-3G
mkfs.ntfs --force -Q -L "3TB_floppy" /dev/sdX

3TB Floppy?

The maximum Floppy disk I'm aware of would be 240MB.  There is probably the final capacity for floppy disks since optical discs killed them in cost per capacity.

 

Here I've composed a detailed graphical snapshot of the 8TB drive in operation in Windows XP in all its legacy glory.

 

"www.msfn.org/board/topic/177171-what-a-single-8tb-mbr-hard-disk-drive-looks-like-in-windows-xp/"

 

 

A more descriptive DOS CHKDSK:

The type of the file system is NTFS.
Volume label is 98SE 8TB MBR EXTERNAL USB HDD.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
Windows found problems with the file system.
Run CHKDSK with the /F (fix) option to correct these.

   7630874 MB total disk space.
   7630652 MB in 16782 files.
     13440 KB in 798 indexes.
         0 KB in bad sectors.
    213888 KB in use by the system.
     65536 KB occupied by the log file.
         0 KB available on disk.

     65536 bytes in each allocation unit.
 122093996 total allocation units on disk.
         0 allocation units available on disk.

U:\>

 

 

As for a Live Linux DVD not at the moment.  Do you have a DOS or Windows equivalent program that would gather the information you're interested in seeing?

 

Edited October 23, 2017 by 98SE

[bphlpt]

@98SE and @rloew, Regarding rloew's EMBR:

@98SE, you seem to be focused on the use of external drives, to either share data between machines, users, and/or locations.  Thus your concerns about the abilities of being able to read the data by a machine that doesn't have the EMBR installed, the cost and inconvenience because a license is required for each machine, etc.

But @rloew, if I understand correctly, your intent was more on the lines of being able to use modern drives on a user's existing machine with an older OS installed, and perhaps other more modern OS as well in a multi-boot arrangement, and so more focused on internal applications.  Since the drive would be "permanently"  installed and NOT shared, @98SE's concerns created by sharing the drives are irrelevant, and a license fee that is per machine, and not based on the number of OS or number of drives installed, seems reasonable.

So have you two been trying to compare apples and oranges?

I'm not trying to argue that external uses are not important or useful, they absolutely are.  Not only for sharing data, but for use with laptops and ease of use in general.  But, if I understand correctly, since external drives often/usually come with a translation bridge built in, aren't they often/usually already able to be used by older OS, eliminating the need for EMBR in that application?

And @98SE, you keep bringing up things like asking why he didn't do such-and-such "20 years ago", or talking about the possibility of using @rloew's tools on HUGE drives that won't exist or be practical for the average user for many years.  While I believe that @rloew is more concerned in addressing the existing needs today of his customers or himself.

Apples and oranges again?

Understanding the reasons a tool was developed is often enlightening, and discussing the possible future applications of a tool can be fun to talk about and sometimes helpful for the developer to give him ideas for possible enhancements to his tools, as long as they aren't continued to be pushed when the developer has stated he's not interested. That hasn't happened in this thread, yet, but it's gotten close.

And isn't the discussion by both of you about GPT veering away from the topic of this thread, regarding MBR hard drives?

Cheers and Regards

[98SE]

2 hours ago, bphlpt said:

@98SE and @rloew, Regarding rloew's EMBR:

@98SE, you seem to be focused on the use of external drives, to either share data between machines, users, and/or locations.  Thus your concerns about the abilities of being able to read the data by a machine that doesn't have the EMBR installed, the cost and inconvenience because a license is required for each machine, etc.

But @rloew, if I understand correctly, your intent was more on the lines of being able to use modern drives on a user's existing machine with an older OS installed, and perhaps other more modern OS as well in a multi-boot arrangement, and so more focused on internal applications.  Since the drive would be "permanently"  installed and NOT shared, @98SE's concerns created by sharing the drives are irrelevant, and a license fee that is per machine, and not based on the number of OS or number of drives installed, seems reasonable.

So have you two been trying to compare apples and oranges?

I'm not trying to argue that external uses are not important or useful, they absolutely are.  Not only for sharing data, but for use with laptops and ease of use in general.  But, if I understand correctly, since external drives often/usually come with a translation bridge built in, aren't they often/usually already able to be used by older OS, eliminating the need for EMBR in that application?

Understanding the reasons a tool was developed is often enlightening, and discussing the possible future applications of a tool can be fun to talk about and sometimes helpful for the developer to give him ideas for possible enhancements to his tools, as long as they aren't continued to be pushed when the developer has stated he's not interested. That hasn't happened in this thread, yet, but it's gotten close.

And isn't the discussion by both of you about GPT veering away from the topic of this thread, regarding MBR hard drives?

Cheers and Regards

To summarize since it's been a long day.

RLoew brought up his EMBR since it is his product so he has the right to advertise it here as long as no moderators have an issue and it is not prohibited on MSFN.  Since he brought up EMBR several times then he could also answer questions about the product and any possible pros/cons of how it would interface with XP and older OSs.  Because it is called EMBR does not necessarily mean it's MBR.  He could have called it RLBR so it would sound foreign and unrelated.

His EMBR is proprietary so only licensed users of it could access the data on those EMBR drives on another machine.  It is obvious if another person was using a licensed EMBR user's machine that's not a problem accessing the data.

As for myself I use both internal and external drives (SATA and IDE) unplugged or plugged through USB SATA adapters if I need to transfer data to it while the system is on.  Or if the system is off I would hook it directly internally to gain better performance.  Most of my machines are desktops not laptops and are usually running 24/7.

The GPT which is the new MS standard will become relevant now and in the future as legacy MBR is capped at 2.2TB.  However since not everyone or I could be the only one that hasn't been quite ready to stop using XP which does not have native GPT support but I may be switching to a GPT compliant OS soon so this might not be an issue in the future.  In the meantime MBR > 2.2TB via USB is more of a stop gap way of continuing to use XP on more than one system without needing to patch each machine and purchase a license for each.  Remember he just said it was per machine.  So if I had 20 machines and I were to use all 20 machine with EMBR that would be a costly approach for one person.  But also my EMBR data could not be read by another person who doesn't use EMBR.  This con has nothing to do with internal or external drives.  Now GPT read/write for both internal and external drives doesn't exist so GPT adoption on XP hasn't materialized yet.  The closest is the Paragon GPT Loader but that is for "internal" drives only.  So in my situation I have no large capacity GPT drives here.  All of them are MBR based so even Paragon GPT Loader has no actual usage until 18TB or possibly 32TB drives when I would be forced to GPT if I want to consolidate the amount of drives I have to use.

You can consider one 18TB MBR drive for one USB port or in the future one USB port for a 256TB GPT drive.  That's 13 USB ports saved to access that capacity.

Concerning internal capacity most OS will be fine with a 128GB MBR drive.  Windows 7 could squeeze in a 32GB partition just fine.  XP can run in 2GB.  So comparing apples to oranges XP still has plenty of usefulness if you steer it in the right direction.  Which is the reason why I'm suggesting RLoew to try to get a Windows 2000 and XP GPT Loader created so that legacy users can continue using XP with extremely large capacity drives that also work in Vista -> W10 without any need for the other computer to have a license to read/write to my GPT drive.  You have to remember even RLoew can't live forever and if he doesn't do it soon and there's no one else willing then XP will be abandoned post 32TB timeline.  Don't forget that everything takes time to complete.  If he were to start today it could take a few years before it's done or it could take a week.  But if it never gets completed and no one is around to do it then I can honestly say XP's usefulness as time goes on will be limited.

Quote

And @98SE, you keep bringing up things like asking why he didn't do such-and-such "20 years ago", or talking about the possibility of using @rloew's tools on HUGE drives that won't exist or be practical for the average user for many years.  While I believe that @rloew is more concerned in addressing the existing needs today of his customers or himself.

Apples and oranges again?

GPT is practical.  Again most people won't be using anything more than 2TB in XP because they don't know how or they moved to a GPT capable OS.  GPT is here and however resistant legacy OS users are it is the future.  The large capacity drives are already here.  16TB SSDs from Samsung in 2.5 laptop form are extremely expensive but more affordable 12TB WD 3.5" drives are already here for $521.99.

https://www.wdc.com/products/internal-storage/wd-gold-enterprise-class-hard-drive.html

 

18TB is nothing to laugh at and reaching the Windows NTFS limit of 256TB is around the corner.

Even though the latest attempt by Jaclaz / Tripredacus to exceed that they were still stuck with two partitions and neither partition could exceed 2.2TB in size.

 

Also the 2.2TB MBR barrier is "broken" so this thread is already in a sense no longer relevant and you can see visual proof.

"www.msfn.org/board/topic/177171-what-a-single-8tb-mbr-hard-disk-drive-looks-like-in-windows-xp/"

 

I'm not sure if anyone else has posted an 8TB MBR drive running in XP anywhere on the internet.  Although most probably can't even figure out how to install XP on Coffee Lake so that number is even lower.

Any healthy discussions of GPT become more apparent as capacities toward 256TB will be reached sooner than you think.  Meanwhile most XP novice users will have to choose to stick with 2TB limits or succumb to Windows 10 and GPT.  This is why whomever creates the first GPT Loader for 2000 and XP will reap the benefits first if done commercially or if someone made it freeware the Legacy OS world would cheer.

Bananas or Pineapples?

 

Edited October 23, 2017 by 98SE

[jaclaz]

2 hours ago, 98SE said:

 

Bananas or Pineapples?

 

Most probably mangoes.

jaclaz

[98SE]

4 hours ago, jaclaz said:

Most probably mangoes.

jaclaz

 No Watermelons?

98SE

 

Edited October 23, 2017 by 98SE

[Dibya]

@98SE it is USB or sata 

[98SE]

1 hour ago, Dibya said:

@98SE it is USB or sata 

8TB SATA 3.5" -> (4KB -> 512 Byte Adapter) -> USB 2.0/3.0/3.1 Port

We need a hardware engineer to find a way to replicate the adapter so it runs off USB power instead of AC power.

18TB MBR USB 2.5" laptop hard drives on XP 32-Bit will be possible.

Edited October 23, 2017 by 98SE

[Tripredacus]

On 10/22/2017 at 7:35 AM, jaclaz said:

That (and nothing else) is the experiment *needed*, that Tripredacus performed (and succeeded with Windows 7 32 bit, but that - for some reasons - couldn't be replicated on XP).

I want to make clear that my testing on XP hit a roadblock, and time/resources to continue the work have not been available to me to revisit. I would not consider this part of the testing to be "done" just because I ran into the problem.

Certainly the testing could have continued if I had access to the hardware that would use the UNIATA driver properly so that the disk could be detected. Since we already knew 1) the disk was OK and 2) UNIATA works to make disks like this work... So that portion of testing still needs to be done yet and is not a closed case.

[jaclaz]

34 minutes ago, Tripredacus said:

I want to make clear that my testing on XP hit a roadblock, and time/resources to continue the work have not been available to me to revisit. I would not consider this part of the testing to be "done" just because I ran into the problem.

Certainly the testing could have continued if I had access to the hardware that would use the UNIATA driver properly so that the disk could be detected. Since we already knew 1) the disk was OK and 2) UNIATA works to make disks like this work... So that portion of testing still needs to be done yet and is not a closed case.

Sure.

Though #2 is not entirely accurate, I don't think we have any actual report of UNIATA working in such a setup,

We know that UNIATA has internal Read16/Write16 support, which should be part of what is needed, but not necessarily *all* that is needed and not necessarily other possible issues that may come from other drivers involved can (or will) be solved.

What we know is (and that may depend on specific hardware and what not), there is a common problem about 3 Tb disks not seen properly (i.e. seen as 746 Gb ones) by XP whilst there are reports of such drives being seen just fine with XP but with access (in Disk Management) limited to the first 2.2 Tb (which is "normal" and what also your successful experiment with Windows 7 confirmed).

For some reasons it seems like most people that have such hardware are not properly documenting their setup (both those that have it working, limited to 2.2 Tb and those that see them as 746 Gb) so it is difficult to understand what is happening and the reasons why, just like it is not clear (in your unfinalized experiment) why the UNIATA wouldn't install properly.

jaclaz

 

Edited October 23, 2017 by jaclaz

[98SE]

7 hours ago, Tripredacus said:

I want to make clear that my testing on XP hit a roadblock, and time/resources to continue the work have not been available to me to revisit. I would not consider this part of the testing to be "done" just because I ran into the problem.

Certainly the testing could have continued if I had access to the hardware that would use the UNIATA driver properly so that the disk could be detected. Since we already knew 1) the disk was OK and 2) UNIATA works to make disks like this work... So that portion of testing still needs to be done yet and is not a closed case.

What exact roadblocks did you encounter that could not be resolved?

Also why did you have to use Windows 7 instead of just XP 32-Bit in your testing?

What software did you use to modify and add the partition and addresses.  Maybe doing in within XP 32-Bit on one of my larger drives (minus) the adapter we would be able to test beyond just 4TB to verify if multiple 2.199 Partitions could be created and work without special drivers as long as XP SP1 was installed.

From what I gathered it was possible to only extend one partition of 2.2TB over the first partition as long as the partition started before the end of the first 2.2TB range in your initial experiments.

Had you contemplated adding another 2.2TB partition possibility if you had a larger drive?

Since you both studied this low level stuff more intensely than I would ever have.

Let's say we had a 10.0TB hard drive just to simply the math.

2.0TB (not 2.2TB) is the actual MBR barrier in this example:

 

The max would be 5 Partitions on a 10.0TB drive.

Part# 1 [0.000-1.998]

Part# 2 [1.999-3.998]

Part# 3 [3.997-5.996]

Part# 4 [5.995-7.994]

Part# 5 [7.993-9.992]

 

Could Partitions #2, #3, #4, #5 Partition location information be stored in Part#1 so any reference to those Partitions could be accessed correctly?

The other big question was did either of you see a way to bridge the two partitions to show up as one large contiguous chunk and appear as one partition somehow to the OS?