Jump to content

Possible to Boot from 4 TB System Volume with BIOS?


NoelC

Recommended Posts

I'm not completely solid in my understanding of the restrictions of installing / booting Windows with a huge system volume.

 

I have a Dell Precision T5500 Workstation based on BIOS, without the possibility of UEFI as far as I know.

 

Presently I have a 2 TB system volume (C:) with MBR partitioning.  Works great.

 

But what if I wanted to make a 4 TB system volume?

 

The advantages would be that with more drives in the array making up the volume performance would be better, and also there would be a huge amount of free space.

 

What would the steps be to partition 4 TB of space using GPT?  Would I be able to install Windows on it?  Would it boot?

 

Thanks in advance for any wisdom and experience you are willing to share.  There's surprisingly little how-to on this out there.

 

-Noel

Link to comment
Share on other sites


Well, not really-really.

 

The limit in size is still there of course, but it is perfectly possible with a few tricks to boot a GPT disk from BIOS, and what happens later depends on the size of disk sector and on the actual OS.

 

A MBR partition entry still has a field for size that is a double word so anything more than FFFFFFFF or 4294967295 can't be wrtten to it, 

so that anything above 4294967295*512=2199023255040 will still become a suffusion of yellow.

 

So, you need anyway a small "system" (MS terminology reversed, "wrong") or "boot" (logical terminology, "right") volume, and then the OS needs to be able to use GPT disks natively.

 

This is normally achieved using a hybrid MBR/GPT disk, which has a number of issues:

http://www.rodsbooks.com/gdisk/hybrid.html

 

The above site http://www.rodsbooks.com/gdisk/is currently the most complete (and seemingly only) source of information on GPT disks in the "Windows world".

 

However:

http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/

http://reboot.pro/topic/20002-map-mbr-style-disk-on-gpt-partition/

 

It is possible to Boot from BIOS on a non-hybrid GPT disk :yes:.

 

Final (at the moment) solution here:

http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/?p=186656

 

jaclaz

Link to comment
Share on other sites

Ah yes, I do remember running across your writeup before - some of the only info out there on the subject.  Though the backflips required to create such a setup initially seem daunting, I'm gathering that once it works, it keeps working unless you try to re-partition the drive.

 

I'm not sure how the needs of the RAID controller might fit into it all as well.  That might be a deal-breaker.  I don't know how many assumptions they make between the BIOS setup and the run-time driver about what's where.

 

Perhaps if I find myself retiring my existing array and building a whole new one (i.e., where I can just plug the old hardware back in and restore functionality in a few moments) I'll experiment.

 

-Noel

Link to comment
Share on other sites

Though the backflips required to create such a setup initially seem daunting, I'm gathering that once it works, it keeps working unless you try to re-partition the drive.

As a matter of fact the (smart? :unsure:) main point of that experimental approach is that the "hidden" partition (i.e. if it is not "indexed" in the GPT partitition table) is pretty much "hidden" and "safe" in "normal operation".

It is placed on sectors 63-2047:

  • the MBR is on LBA 0
  • the EFI PART header is on LBA 1
  • the GPT partition table will be starting on sector 2 and extend up to sector 33 for 128 available partition entries - unless you create a zillion partitions/volumes in it, it will *never* reach sector 63
  • the Disk Manager and/or diskpart in the default settings will do nothing to any sector before 2048 on a largish disk
  • the adding or removing of volumes will affect the GPT partition table but not the MBR, leaving untouched the protective entry and the code (that should not be there)
  • changes (if any) in Disk Signature will obviously not affect anything "on disk" though depending on the actual contents of the \boot\BCD in the "hidden" partition this may need to be adapted

So, in practice only if you manage to delete the Magic Bytes 55AA from the MBR (thus creating the need to re-initialize the disk) you will have to "re-start from scratch", but if you re-initialize the disk you need to start from scratch anyway.

 

I'm not sure how the needs of the RAID controller might fit into it all as well.  That might be a deal-breaker.  I don't know how many assumptions they make between the BIOS setup and the run-time driver about what's where. 

If it's a hardware controller, it's operation is AFAIK "completely transparent" to BIOS (and of course as well to MBR code and grub4dos), so it should not change anything.

 

jaclaz

Link to comment
Share on other sites

Or maybe, just maybe, Microsoft will work things out so that ReFS becomes available for use as boot / system volumes, and in the process of doing so will rework the boot mechanics so that the boot / system volume can be any (practical) size and the setup of same can be done by any member of the Federation, not just the pointy-eared variety.

 

Has anyone heard of any progress with ReFS?  I've been running data volumes with it for over a year now with no apparent problems.

 

Edit:  But on reflection, I'm thinking they wouldn't give a darn about BIOS any more.  Guess I need to start thinking about a newer workstation.  More cores, faster cores, and of course the wonderful new Unified Extensible Firmware Interface - the answer to all prayers.

 

-Noel

Edited by NoelC
Link to comment
Share on other sites

Or maybe, just maybe, Microsoft will work things out so that ReFS becomes available for use as boot / system volumes, and in the process of doing so will rework the boot mechanics so that the boot / system volume can be any (practical) size and the setup of same can be done by any member of the Federation, not just the pointy-eared variety.

But this has nothing to do with the actual filesystem, the "normal" NTFS can do nicely much more than any "practical" size :

http://en.wikipedia.org/wiki/NTFS#Scalability

 

The good MS guys introduced artificially (as they often do) an incompatibility between BIOS based hardware and GPT disks, or better didn't bother to update the real mode part of the BOOTMGR, most probably in order to push the EFI/UEFI platform, there is no real reason why the non-EFI bootmgr cannot access/understand/parse/use GPT volumes.

 

jaclaz

Link to comment
Share on other sites

@NoelC: With all due respect:

 

ReFS and exFAT are just two more (of the many) ways MS has of imposing closed-source, undocumented, unnecessary standards, where they aren't really needed at all... *and* to support and promote them is tantamount to supporting and promoting evil things like Metro / Universal UI. :puke:

 

Now, creating a free update to the real-mode part of the BOOTMGR to allow the non-EFI version GPT capabilities, OTOH, might be a really worthy project, and maybe even demand not too much time to reach real-word usability. :angel

Link to comment
Share on other sites

Now, creating a free update to the real-mode part of the BOOTMGR to allow the non-EFI version GPT capabilities, OTOH, might be a really worthy project, and maybe even demand not too much time to reach real-word usability.  :angel

And, conversely, now that CHS is not used anymore in actual OS operations, it would be trivial to invent a "new standard" :w00t: where the CHS area of the MBR partition entry is used to hold the further "high bytes" of the LBA addresses, giving it a new "generic" protective partition ID, by stealing  :ph34r: one of the ID's that are unused and that were (senselessly) claimed or "reserved" by Operating Systems that never were or that are totally irrelevant/abandoned: 

http://www.win.tue.nl/~aeb/partitions/partition_types-1.html 

so that the only limit/requirement for booting with an UNmodified BIOS would be that the Active partition has "conventional LBA addressing" and resides within the first 2.2 Tb of the disk, making m00t of the supposed *need* for GPT disks.

 

For the record the *only* "advantage" GPT disks have in "real world" is (besides the larger addressing extents) that you can have countless (like 128 or more) primary partitions (not really a "limit", since most people seemingly use single extremely large volumes and rarely needs more than 4, and even when they do, logical volumes work fine since what 20 or more years) and the freedom from the 256 partition ID's limit, which, given that the available number is now so mindboggingly huge makes it improbable that there will be a collision (see point #7 here): 

http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/?p=186493

 

And - still for the record - more wasted bytes:

http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/?p=186341

 

jaclaz

Link to comment
Share on other sites

ReFS and exFAT are just two more (of the many) ways MS has of imposing closed-source, undocumented, unnecessary standards, where they aren't really needed at all... *and* to support and promote them is tantamount to supporting and promoting evil things like Metro / Universal UI. :puke:

 

Ah, no.  The file system implementation has substance; Metro/Modern does not.  Probably why we haven't seen advancement of the former.  No one's left in the Republic who commands the light side of the force.

 

Some of the things ReFS brings to the party are actually good.  That said, I've had zero problems with NTFS in all the years since there was NTFS.  I don't see a need for a new file system, honestly, I just brought it up because one claim to fame is virtually unlimited size, and that bears on this problem.

 

-Noel

Link to comment
Share on other sites

Sure. I do understand why you you've brought it up.

 

No matter whether ReFS is great, and I actually don't intend dispute that, it's simply not needed. exFAT much less. Why move on to proprietary FSes, when none new is actually needed? Just to shower money onto MS for them to develop their follies? It makes no sense to me, sorry, none at all, actually! :wacko:

 

Now, fact is: there's NTFS, then there's Ext3 and Ext4. And for non-journaling, there's FAT32 and Ext2. :yes:

 

While it sure is good to have alternatives for when those trusty FSes are not enough, I don't think proprietary FSes are the way to go anymore... not now, and much less later on. Just my 2¢, of course!

Link to comment
Share on other sites

I don' t know. :unsure:

 

I mean, I do like some of the features of ReFS, but it's not like any of them (BTW nice) are really-really *needed* or *make a difference* in practice when compared with NTFS (the exception would be of course data centers and similar where they most probably use Zfs or the like, not the PC). 

 

exFAT (which the good MS guys managed to bastardize releasing - without documenting it - a few slightly different versions, including TexFAT) makes no sense at all, if not - maybe - on dedicated hardware (like the phones, and the like).

 

In practice the filesystem that never was :w00t::ph34r: (though it is available in newer systems) given a chance is UDF (that besides the pompous and extremely inaccurate name, since noone uses it if not on optical discs) which would be otherwise particularly suitable for storage or for USB sticks and the like.

 

jaclaz

Link to comment
Share on other sites

Thanks to all who made suggestions.  It is now clear that there's no direct, supported way to accomplish my original goal with this BIOS-only system.

 

I've decided to stop short of going through processes that require reading tens of pages of forum threads for specific instructions and downloads of different operating systems in order to set up a system that boots a single large partition.  The difficulty in doing it and especially the risk of it stopping working in the future are too high.

 

At this point my alternative is to set up 8 x 512 GB SSDs as a 4 TB RAID array that I partition into a max-sized boot partition (C:) and a second partition containing all that's left (D:).  I'll move from C: to D: several large sets of data (in the hundreds of gigabytes range) that grow slowly or not at all - my photo data, astronomy data, and active virtual machines.

 

This approach will 1) have all the drives working in tandem for all I/O operations, boosting performance a good bit over the 4 drive array I have now, and 2) there will be much more free space available for temporary use as needed on C:.  Both partitions will have room to grow for quite a while.

 

Using the current 992 GB of C: drive data usage at the moment as a basis, this reorganization would initially work out as follows:

 

C:  275 GB used, 1800 GB free

D:  717 GB used, 1100 GB free

 

The only real downside is that the free space is not in one usable chunk, but two.

 

And while having two separate partitions would complicate my backup strategy slightly a little, in fact it could be somewhat an advantage to remove a large chunk of data from the regular System Image backup and rely on my file backups (which currently also include these files) for the data moved to the D: drive.  I'll probably have to get a bigger second external drive (right now I have a 3 TB and a 1 TB USB drive; the latter would be replaced with a 3 TB or 4 TB drive to allow room for growth).

 

Thus I'll have plenty of room for both C: and D: partitions to grow, as well as improved I/O performance, for a long time, no doubt well beyond the time this workstation is obsolete (and then I'll just move the array to a new one).

 

It's nice that SSDs are so compact and use so little power that it's quite reasonable to put 8 of them inside a desktop chassis.  But even if I couldn't, there's the possibility of an external chassis.  Decent RAID controller cards like the Highpoint 452x series offer both internal and external capability.

 

-Noel

Link to comment
Share on other sites

I've decided to stop short of going through processes that require reading tens of pages of forum threads for specific instructions and downloads of different operating systems in order to set up a system that boots a single large partition.  The difficulty in doing it and especially the risk of it stopping working in the future are too high.

Maybe you are making it a bigger issue than it really is.

 

If you can afford 8x512 SSD's you can probably afford another tiny "boot only" device.

 

BUT your alternative is actually much better than the original idea of having a huge single boot and system volume, IMHO.

 

jaclaz

Edited by jaclaz
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...