Tom Del Rosso said:
With Seagate's driver, can you use a 3TB secondary data drive with a single
partition in XP?
Max partition sizes:
- NTFS: 16 exabytes
- Basic MBR: 2 TB (see note)
- Dynamic volumes (spanned drives): 16 TB
These limits can be increased by enlarging the cluster size; however,
that also means you waste for space for the slack space in a cluster not
completely consumed by a file. Some drive setups require the 4 KB
cluster size.
Note: While NTFS has a max partition size of 16 exabytes, the old basic
MBR structure (the first sector in the first track in the first
BIOS-detected hard disk, and not part of any OS) has 4 partition table
entries and each has a limit to define up to 2 TB partitions (2^32 times
512 bytes/sectors using LBA mode = 2 TB). The old basic MBR structure
and its partition tables is limiting the partition size hence why the
GPT (Guid Partition Table) structure evolved to extend the maximum
partition size but the BIOS has to support the GPT structure (although
it may not support the rest of the EFI spec).
See:
http://en.wikipedia.org/wiki/Master_boot_record
http://en.wikipedia.org/wiki/GUID_Partition_Table
The only scheme I remember having used or know about is where the
"driver" (which is NOT part of any operating system) replaces the
bootstrap code area of the MBR. This is the code that the BIOS loads
into memory and to which it transfers control. The bootstrap code reads
the MBR to find out which partition table entry is currently marked the
"active" one, reads that partition table to find its start, reads the
boot sector from that partition and loads the code there into memory
(the kernel loader for the OS) and transfers control to that boot sector
code. By replacing the MBR's bootstrap code, you can run, for example,
a multi-boot manager (e.g., GAG at Sourceforge.net) or a translator used
to extend the abilities of the BIOS or extend beyond the partition size
that the current 32-bit partition table in the MBR can reach. I haven't
used one of those MBR-usurping partition translators in probably around
15 years. A problem with them is that they replace the bootstrap code
in the MBR which might already have been usurped for another purpose,
like for multi-booting or whole-drive encryption. The MBR-usurping
program is not necessarily limited to just the 446 bytes allocated in
the MBR structure for its bootstrap code area. The rest of the first
track cannot be allocated to a partition so that space can be used for
more code.
Support for Disk Drives Beyond 2.2 TeraBytes (TB) and 4K Advanced Format
Sectors
http://knowledge.seagate.com/articles/en_US/FAQ/218619en
"The device driver mounts the capacity above 2.2TB with another MBR
which looks to the system as a second virtual ´physical¡ device."
So it looks like they are chaining together multiple MBRs: the first one
is the standard MBR structure, the 2nd is their own format, and they
would have to replace the initial (first) MBR's bootstrap code to do
that chaining. That means you must be using only the standard MBR
bootstrap code when it gets replaced (usurped) by Seagate's "driver".
If you already usurped the MBR bootstrap code with a multi-boot manager,
or another old partition translator (because your mobo is really old and
needed the translator to get past the 128GB boundary), or you use
whole-drive encryption (which uses the bootstrap code to prompt for a
password to access anything on the drive), or with anything else, it
will get overwritten with Seagate's "driver" because it also usurps the
MBR bootstrap area. I've only run across one MBR-usurping program that
would chain the old MBR bootstrap code with its own bootstrap
replacement. In almost all cases, when the MBR bootstrap area gets
usurped, whatever was there before gets discarded.
I'm assuming the sane solution of replacing the bootstrap code in the
old MBR structure to insert code that will somehow handle partitions
that are larger than the 2TB that the normal MBR partition table entry
can handle. If instead they let you define only up to a 2GB partition
in the old MBR, load Windows, and then load a driver under that
environment that will then load a virtualized partition to extend the
real one then you will not be able to use that whole real+virtual
partition outside of Windows. When you boot to Recovery Console mode or
boot using another CD or USB flash drive (to repair your Windows install
or for whatever reason you boot another OS) then all it will see is the
2GB partition from the MBR's partition table. It won't know about the
extended or virtual partition that gets added to the real MBR-defined
partition. That seems to be a disaster waiting to happen.
So why do you need such a huge C: drive? Why can't you create a 2TB
partition for C: and slice up the remaining disk space into more
partitions for other drives? Obviously you don't need 2TB for
installing Windows. It's also unlikely that you are filling up your C:
drive with application installs (the exception being maybe having LOTS
of games that permit you to save all their files to the hard disk). For
all those *data* files (movies, letters, audio, virtual machine disk
files, backup images, etc), put them on other drives that are in other
partitions.
It isn't Windows XP that physcially limits the partition to a max size
of 2 TB. It's bit size (32) for addressing in the partition table
entries in the old MBR on your hard disk(s) that your mobo's BIOS uses.
The MBR isn't part of any operating system. When the MBR bootstrap code
is ran, no OS is yet running.