As title. Thanks in advance！！

Patrick

Hi the 64bit you refer to is the CPU archietecture and nothing to do with the Master Boot Record (mbr)

The 2TB limitationm refers to windows only. Linux can see much larger drives depending on your file system.
Windows uses FAT's with linux the equivalent is inodes and depending on the choice of file system you can access up to
16TB on ReiserFS or 32TB on ext3

More info below


http://wiki.answers.com/Q/What_is_th..._size_on_Linux

Thanks hal8000b!

But there IS a limitation on the MBR partition. I agree with you for non-booting partition, Linux can manage way larger partitions.

From MBR WIKI

Why would you need such a huge MBR partition? Not even the root partition needs to be that big?

I am not implementing this huge partition for real. Just to want find out the possibility and how this works.

There is no "MBR Partition". The MBR is defined as the 1st sector of the drive, and contains the initial boot code + the primary partition table.

From your first post, perhaps you mean the partition mounted at /boot. This can be as big as can any other Linux partition.

If we know what problem you are trying to solve, we might be more help.......

Thanks again all guys for the reply.

Yes, MBR partition is not accurate. I should say the booting partition with bootstrap from MBR. However, I don't think the booting partition can be more than 2TB regularly, with MBR. If it can, GUID Partition Table will become meaningless.

Please read 'MBRs and disk partitioning' section of MBR WIKI (http://en.wikipedia.org/wiki/Master_boot_record) if you don't believe me.

My question is on a 64bit Linux, the statement of 2TB limitation on the WIKI still stand true?

Why do I think that Hal8000b already answered this?......

Yes, the limitation still stands. As hal8000b said, 32bit or 64bit kernel is not relevant to the issue.

However, hal8000b's second statement is incorrect. The limitation is not windows only. It's a limitation of the partition table itself which as you have already quoted is limited by a 32bit value used for the LBAs. On a 512 byte per block disk you have an effective limit of 2TB of addressable (within the partition table) disk blocks.

If you want to exceed 2TB then you need to initialise the disk with a GPT format partition table and define your partitions within that. You'll also need to have GPT support enabled within your kernel, which some distros don't have.

To determine what you can boot and what you can't boot there are only two relevant pieces: your boot record (whether it's an mbr or anything else) and your bootloader.

By the time grub or anything else loads, linux is not loaded, windows is not loaded, foobarOS is not loaded, so none of them has any saying in what's happening at the moment. It's nothing to do with the OS bitness nor with the fs, because the boot record to start with is fs agnostic, it's outside the partition and outside the OS. Once the OS has booted it will take on managing your partitions, and the fs drivers are the ones that will determine the maximum size of a given fs, the mbr has nothing to do here, it's just used at boot time.

The MBR partition here I think refers to the /boot partition, which should be no greater than 100MB. It is recommneded that the /boot partition be setup apart by itself from all the other partitions, including the root partition, especially if you use LVMs. It is also easier to recover from a bad disk if this partition is setup by itself.

Thanks GazL and i92guboj for by far the most informative explanations!

For those of you confused on this issue reading the MBR wiki and another redhat KB (http://kbase.redhat.com/faq/docs/DOC-16981) would be helpful.

cybeijing, you are welcome.

For those still confused about the issue, as I said above, 64 or 32 bits linux is irrelevant. This is the boot manager (usually grub or lilo) land. The OS is not loaded, you still haven't chosen one from the menu, so it can't interfere in any way at all.

Again, what is bootable and what is not only depends on your boot record and the boot loader you use. Period.

In any case, the grub tools are always compiled as a 32 bits binaries, regardless if you use a 64 bit Linux, they simply have not been ported to 64 bits. Irrelevant as well, since it wouldn't make a difference as long as you continue using an MBR-based boot record system. The MBR has a finite space (512 bytes), and that the key to understand what this thread is about. Only 64 of these 512 bytes are devoted to the partition table, and in that space simply there's no space for numbers that are bigger than 2^32.

In these 64 bit boxes we have 16 bytes for each partition. From these 16 bytes, the first 8 are used for a few different things, the last 8 are used this way: 4 bytes (32 bits) to define the offset where the partition starts, and 4 bytes (32 bits) to define how big the partition is. The size is in sectors, which is the minimum unit that a drive handles. Unlike ram, HD's are simply not able to do byte-by-byte indirections, either you read a sector or you don't. Either you write a sector or you don't. But you can't pick half of it, or a single byte, at hardware level.

A sector is 512 bytes, so this means that the max offset you can use in the mbr is (2^32)*512 bytes, which is also the max size for a given partition as per the MBR specifications. So, the most extreme case that an MBR can handle would be a partition that starts at 2TB-1byte position and that is 2TB big. Nothing can change this, no matter what OS or architecture you use, as long as you keep using an MBR model.

If you use a different boot record system that can hold bigger numbers then that's another story, but then the whole point is moot because we would not be speaking about MBR at all, which is what these thread is about.

And again again again: this is the boot loader land. This has absolutely nothing at all to do with the capacity of your SO to handle bigger partitions while running. Your OS has drivers, big drivers, and a big kernel. Grub, unlike Linux, is not a whole OS, and has limited capabilities.

Just to expand on what i92' has said. Although he's quite correct and you'll get the kernel started (assuming the bootloader can access it), it won't be able to detect any partitions that go above the 2TB mark unless you use a GPT partition table, so you'll have a running kernel, but no access to the filesystems on them as the block devices for them will be missing.

We had this issue come to light in the slackware distro forum a few weeks back when someone was trying to use a partitioned RAID array and not all the partitions were showing up in the dmesg.

Have a look here if you're interested in seeing how the error manifests itself.

edit:

Just want to add that, that example was for extended partitions (which are a little weird as they are chained one from another). A primary starting at 2TB - 1 block as i92' describes above might act differently.

Thanks GazL, I'll be checking that thread, interesting stuff.