Talk:Master boot record

This article is PC-compatible specific (as well as too heavily focused on Microsoft operating systems), yet doesn't make that fact clear to the reader, who may wrongfully assume that all computers work this way at boot time (obviously they don't).

Also not mentioned is the fact that there is no wired-in requirement that a PC's MBR contain a partition table or that the attached disk even have partitions. If one examines the boot loader part of a PC BIOS, one will note that the loader doesn't look for a partition table at all. It only loads the MBR into RAM and points the MPU to byte zero of the MBR image. What happens afterward, including the analysis of a partition table (if present), is determined by the MBR code. This fact needs to be clearly set out in this article.

Equally unclear is the relationship between the MBR boot code, which has very little capability and partition boot code, which is what is responsible for loading and starting the kernel in most OSes that are runnable on PC hardware. This article needs attention from someone who is expert on this aspect of computer operation, as well as a good wordsmith. I'm very savvy when it comes to computers and found this article confusing and rambling, not encyclopedic in nature at all.

Lastly, most non-PC systems handle boot from disk very differently than a typical PC. For example, HP PA-RISC systems do not have the concept of a partition table and assume that the entire extent of the disk is addressable as is. Can we make this sort of information clear to the reader as well?

Bigdumbdinosaur 17:50, 15 November 2009 (UTC)Reply

There's a general bias towards peecees on Wikipedia which is hard to get rid of. I've tried in the past to address it on several articles but it is pointless fighting against the tide. In this instance though I think it is largely justified. MBR is a PC term and only used on other platforms that copied wholesale the PC's disk layout. The platform-independent term would be boot sector - that page has far too much emphasis on PCs but that is not a problem with this page. As for the fact that a boot sector need not contain a partititon table this is addressed in the lead:

The boot sector of a non-partitioned device is a Volume Boot Record...

I agree it could be put into context a lot better than it is, and that is probably something we should work on, but this is an article on a specific topic. Putting it into context implies showing how it relates to other specific areas but we do not need to cover those areas in detail here - indeed this article would lose focus if we attempted to do so. CrispMuncher (talk) 20:54, 15 November 2009 (UTC)Reply

I've reworked the introduction as well as some of the following sections to try to make the fact that the entire article is about terminology and conventions specific to PC compatible systems as explicit as possible. Triskelios (talk) —Preceding undated comment added 21:36, 10 August 2011 (UTC).Reply

You said:

[The BIOS boot loader] only loads the MBR into RAM and points the MPU to byte zero of the MBR image. What happens afterward, including the analysis of a partition table (if present), is determined by the MBR code. This fact needs to be clearly set out in this article.

I just did some editing on the article, and in the process without having previously read your comments, I noticed the same...void, shall we say... and added a paragraph that does just that: clearly sets out that point. Of course, the community is invited to mercilessly edit it into the ultimate eloquent form.

I also found the article to be rambing, not well organized, and redundant. I think it needs a good rewrite. The contained information is very good, and the phrasing of most sentences is pretty good, but the overall composition is fair to poor. I think it ought to be organized along the lines of conceptual layers--what BIOS defines and does, what MS-DOS (the originator of the MBR partition table format) defines and what its MBR does, relationship of MBRs to VBRs, and then extensions and variations defined and implemented by different (operating) systems, taken one system at a time rather than one aspect (e.g. handling of DS:SI passed from MBR to VBR) at a time. This would take out a lot of the redundancy--the same points stated separately, almost word for word sometimes, in different sections and different paragraphs of the same section (e.g. the issue with the Apple Darwin VBR assuming zero for a segment address). Unfortunately, I haven't got the time to do the rewrite myself now, but maybe in a few months, eventually...

--Stephen 74.109.14.154 (talk) 04:12, 6 June 2013 (UTC)Reply

I just removed a recent edit from User:86.17.213.200 who claimed that something called "diskman" has a 16-entry partition table MBR. The only "Diskman" reference I could find was to a hard disk partitions manager program that makes changes to partitions on a disk. All the help; even its text file, are in Chinese, so I admit it's possible the program could alter the MBR sector, but I saw no evidence of that when running the program. Does anyone know if this disk manager can create its MBR code with a 16-entry partition table all in the first sector of a hard disk? If so, I'd be interested in finding an English reference and add that to the MBR article. Daniel B. Sedory 02:36, 28 October 2007 (UTC)Reply

I haven't seen the original edit, but from your description it is very clear, that the original edit was correct. Some very old versions of Disk Manager did in fact use a custom Master Boot Record with a Partition Table holding 16 entries (instead of only 4). Some OEM versions of MS-DOS (prior to 3.31) also utilized MBRs with partition tables holding more than the typical 4 entries (up to 8 come to my mind right now, but I would have to look this up). At these times, the concept of extended partitions and logical drives had not been implemented, so various OEMs and third-parties invented their own methods of how to take advantage of larger hard disks than the maximum partition size DOS could access through a single primary partition. The idea was to split the space into multiple primary partitions and make them available to DOS by tricky software such as Disk Manager or alter the DOS-BIOS accordingly (as in various OEM issues). I think this is also documented in RBIL.

This trickery became obsolete when DOS finally (after many years of stagnation) implemented extended partitions and logical drives (with DOS 3.3 IIRC) to have more partitions, and allow for 32-bit sector addressing (as with FAT16B since DOS 3.31) to have much larger partitions.

--Matthiaspaul (talk) 14:57, 13 December 2011 (UTC)Reply

This may be a somewhat complex topic but methinks something should be mentioned about partition alignment--especially the traditional cylinder boundary partition alignment. This is important for a few reasons--not the least of which is that Vista has a different default partition alignment scheme than previous MS OSes (and other OSes that have copied the IBM/MS MBR partitioning scheme). Also partition alignment can affect performance--especially with larger sector drives that emulate traditional 512-byte sector drives (e.g., LBA to CHS mappings that use 63 sectors per track lead to poor performance due to these cylinder boundary partition alignments). 96.225.224.216 (talk) 19:50, 6 December 2008 (UTC)Reply

Hi, years later, alignment should not affect performance: You work with sectors in a partition, you rarely care about its first sector. Yes, traditionally partitions started at a cylinder boundary (C=x, H=0, S=1) or at least track boundary (C=x, H=y, S=1), and this info helped when looking for a lost partition. But 255 63 is not more related to the physical geometry of hard disks in this millennium, therefore the new MB alignment is also fine for the purposes of finding lost partitions with tools such as TestDisk. If you have tools claiming the rest of the first track for their own business (backup of MBR or similar) you could be in trouble if your first partition does not leave this gap and starts directly in CHS 002. That could be another (weak) argument for some kind of alignment, tools doing odd things with resulting gaps. –89.204.153.224 (talk) 08:33, 19 July 2011 (UTC)Reply

The multi boot article is flagged as potential original research. I don't see that it discusses the strange case of an MBR defining a partition containing the MBR. That's what the article says at the moment: A multi boot record can be used as both an MBR and as a volume boot record in the bootstrap process. I've flagged both with {{fact}}. The partition table is small, there are lots of space to do interesting things, e.g., let the user pick a boot partition on the fly. The parameters for file systems such as FAT32 or NTFS are not so small, they would occupy more than 80 bytes (incl. jump to volume boot code). The article explains, that 440 bytes are available for code, so that's down to less than 320 bytes for FAT32 or NTFS. The primary task of an MBR has still to be done (find active partition and boot it, throw in some plausibility tests). If the first partition is the active partition the proposed case of a combined MBR + VBR would also contain code for this job, e.g., find a FAT32 or NTFS file such as NTLDR in the active partition, check plausibility + load + run it, or report trouble (NTLDR missing or compressed or whatever). 320 bytes are quite a lot. But I don't believe it before I see it. An .asm source or even binary would be more interesting than a citation from my POV. –89.204.153.227 (talk) 15:25, 18 July 2011 (UTC)Reply

Take a look at e.g. a floppy disk, where the master and volume boot records are one and the same thing. Even on the hard drive of this system here they are merged since it uses a BSD disklabel for actual partitioning. There's still a multi boot loader on there. Crispmuncher (talk) 16:25, 18 July 2011 (UTC).Reply

You raise a very important terminology question. As far as I'm concerned there is no master boot record on a floppy, it has an ordinary volume boot sector. From my POV an MBR by definition contains a partition table, as explained in the article here. The not yet verified case, where the MBR itself is also the VBR of the first partition defined in this MBR would be a fascinating hack. Nothing is wrong with explaining good hacks in Wikipedia, but it should be very clear that it's not the normal state of the art. At the moment the hack is a sentence with a link to an article flagged as potential original research without any indication how unusual this approach is, and where it was actually successfully used for what purpose. –:89.204.153.224 (talk) 07:13, 19 July 2011 (UTC)Reply

Quoting Technet: "There is no MBR on a floppy disk. The first sector on a floppy disk is the boot sector. Although every hard disk contains an MBR, the master boot code is used only if the disk contains the active, primary partition." [1] –89.204.153.226 (talk) 22:19, 19 July 2011 (UTC)Reply

I agree: There is no MBR on an unpartitioned PC medium such as a floppy disk, only a VBR. The view that a floppy has both and they are one and the same is interesting but unconventional; I have been hacking on IBM compatibles since the XT era, before hard disks were standard equipment—and before I knew I was hacking—and this is the first I've heard that perception. Historically, it goes against the fact that the MBR was invented as a surrogate VBR to get multiple volumes of the exact format that was conventional on unpartitioned media onto a single fixed disk (which was too large, at 20+ MB, to conveniently contain just one volume of the typical FAT16 [32 MB-limited, MS-DOS 2.0–3.2 ] type). Since in the beginning there was no MBR, it is unhistorical to say the floppy disk's VBR was also an MBR. However, that said, viewing things from a different perspective, "out of the box", can lead to useful insights that can ultimately lead to creative and sometimes even exciting new engineering ideas and solutions, so I want to express my respect for the thought and don't want to discourage unconventional thinking. Despite its possible intellectual value, I just want to affirm that this particular description of the relationship between MBRs, VBRs, and floopy disks is not encyclopedic.

I also note that the distinction between MBR and VBR is at an abstract software level above the BIOS. I have just tonight added a clear exposition of this to the article, in the Programing Considerations section. To BIOS, there are no MBRs or VBRs, only generic boot records which it loads, checks, and runs, giving them full control. Based on this point, as for the ability of the MBR to function as a VBR conventionally does as well, I think it's absolutely possible. The assertion that an MBR or VBR directly loaded by the BIOS boot loader can do anything clearly implies this. The only special technique needed would be for the boot record, when behaving as an MBR, to pass some signal to the VBR which it itself could use to detect that it was being called as a VBR (i.e. by an MBR) and not as an MBR, or for it when acting as an MBR to detect when the VBR was itself and to then jump to its VBR entry offset (not at 0) instead of its MBR entry address (at 0). Doing either of these is trivial and many methods are obvious. (Therefore, there is no need for it to be explained in the article, even if it were established published work). –74.109.14.154 (talk) 04:47, 6 June 2013 (UTC)Reply

Actually, the MBR and up to 4 partitions per drive structure was first introduced in order to allow for multiple operating system installations on a hard drive. Multiple DOS partitions on the same physical disk was not at all common until the DOS 3 days. AnonMoos (talk) 13:50, 6 June 2013 (UTC)Reply

User:Triskelios removed the unverified fascinating hack — I fear it was simply patent nonsense — again, so that's hopefully settled. Thanks –89.204.153.224 (talk) 01:03, 25 July 2011 (UTC)Reply

It appears Master boot record, Boot sector and Volume boot record are covering only slightly different aspects of the same concept. I propose the latter two be merged into this article.\ as it is the most well-developed. --Kvng (talk) 21:27, 5 December 2011 (UTC)Reply

The MBR/VBR are implementations specific to PC compatible systems, so while I wouldn't mind merging those two into a single article, this article should remain separate since it is about a generic concept. 71.184.245.22 (talk) 23:37, 11 December 2011 (UTC)Reply

That's a start. Why does PC-specific content need to have a separate article? Can't it be a subsection in a more general article? --Kvng (talk) 14:39, 13 December 2011 (UTC)Reply

I agree to *separate*! and to do all the linking each other. When it comes to floppy or (any other) originate question one (should) search for PBR(VBR) and NOT *MBR*. MBR (and best-done file-solution NTLDR ...) is "just" an extension. The better sequential understanding of what the system is (still (35 years later or so)) processing is to start IBM/VBR. The most need for this nowadays is to understand all the various boot-manager programs/loaders (Paragagon ...) AND all these bootable usb-drive makers/loaders and why supposed bootable-iso-image doesn't boot and why it doesn't function as wished at all. For (Lu)nix users no problem at all, but windows user have problems, for sure. Sensefull linking to each other articles, also lilo and grub and freedos and so on, should be done. Rest: separate. — Preceding unsigned comment added by 188.100.213.145 (talk) 23:43, 18 June 2012 (UTC)Reply

A Volume Boot Record (among other names) and an MBR (Master Boot record), are two completely different things. Put simply, the MBR is on the first sector of a hard drive preceding ANY partitions, while a Volume Boot Record (among other names) resides within the confines of a partition. --tallship 23 June 2012.

I don't think, merging the MBR, VBR and boot sector articles would be a good idea. While there is some redundancy (and there will be more, once the articles are fully flesh out), there's enough material specific to MBRs and VBRs to justify seperate articles. Also, while the generic stuff holds true for both of them, there are also many differences, and merging this would be confusing. The general concept of boot sectors can be explained in the boot sector article. This article is rather PC centric at present, but boot sectors of other platforms could be discussed there as well. At the same time, we should move the PC specific details to the MBR and VBR articles and only leave a very basic primer on PC boot sectors in that article. --Matthiaspaul (talk) 18:53, 20 August 2012 (UTC)Reply

Have any IP claims to the MBR been raised? I know that Microsoft has made claims to the FAT filesystem (the TomTom case), but that's at the partition level. What about the partition map layer which would be what MBR is (or GUID or whatever other partition map schemes exist)? — Preceding unsigned comment added by Jimw338 (talk • contribs) 21:56, 29 April 2012 (UTC)Reply

The answer is "No", if you mean the design of the partition table or the way how MBRs "work" functionally.

The actual code in the MBR, however, is owned by whoever wrote it, and you are not free to incorporate the "standard code" found on most partitioned hard disks in own development projects (as is sometimes seen). You'd have to develop your own functional equivalent code. --Matthiaspaul (talk) 09:47, 1 May 2012 (UTC)Reply

The discussion below has been copied from inline HTML comments in the text of the article, section Master boot record#Partition table entries.

Please note that making large inline comments is a very obscure way of dispute resolution. Please use the Talk page for discussions so other editors can follow your arguments and make their opinion. --Dmitry _{(talk•contibs)} 15:57, 29 December 2012 (UTC)Reply

For disks that present a sector size other than 512-bytes, there are limitations as well. A sector size of 4,096 results in an eight-fold increase in the size of a partition that can be defined using MBR, up to 16 TiB−4,096 bytes.{{citation needed}} Versions of Windows more recent than Windows XP support the larger sector sizes as well as Mac OS X, and the Linux kernel has supported larger sector sizes since 2.6.31

While they may support larger sectors, this does not necessarily mean that the partition table should not be continued to be interpreted as for 512-byte sectors, given that the partition table is tightly coupled with INT 13h and classical INT 13h functions don't provide any means to retrieve or set the sector size. Transfering more than 512 bytes would break virtually all BIOS dependent code and operating systems. — Preceding unsigned comment added by Matthiaspaul (talk • contribs) 03:21, 14 August 2012 (UTC) [2]Reply

True, but SCSI disk drivers have never used BIOS I/O functions. — Preceding unsigned comment added by Linush100 (talk • contribs) 19:33, 14 August 2012 (UTC) [3]Reply

We can have larger physical sectors on hardware level and larger logical sectors on higher levels. While there are operating systems supporting larger sectors (even some versions of DOS such as DR-DOS do), this does not mean that the partition table in the MBR should be interpreted as for larger sectors as well (this is very different from BPBs, where it is possible to define larger sectors). Transfering more than 512 bytes would break virtually all BIOS dependent code and operating systems, as buffers would be too small. All works I checked on this topic (including original information from IBM, Microsoft and others) so far clearly indicate that the MBR entries are for 512-byte sectors only (even if the sector itself may be larger). INT 13h functions do not have any means to retrieve the sector size. This was added much later with EDD and LBA only, but we cannot rely on this. I see no way to change the definition in a way, which does not break all existing code. And if we'd still do, there is no purpose, as new operating systems can always use GPTs. Changing the definition would only make sense if there is a benefit for older systems (so that they can use it or at least can coexist). What I would like to see here are examples of operating systems using the described trick or references indicating that it is okay to assume larger sectors in the partition table as well. Even an example of an INT 13h CHS "read sector" function returning more than 512 bytes per sector on some obscure machine (even if very old and long forgotten) would be enough. — Preceding unsigned comment added by Matthiaspaul (talk • contribs) 22:56, 15 August 2012 (UTC) [4]Reply

Most AF drives available today use 512e, so the main issue with them is alignment. We should probably distinguish between booting from a large-sector drive and having a second large-sector drive that is not used for booting. Because of the BIOS and other s/w, booting from a large-sector drive presents a bigger challenge. However, whether the drive has an MBR or GPT will not affect any issues that arise from it having large sectors. If a large-sector drive works when it has a GPT, it should also work with an MBR as that will not affect issues with allocating proper size buffers. The Linux kernel is, from what I have seen, ready for large-sector drives. Booting requires all the supporting pieces be in place and I understand that is also possible. There's nothing about the MBR that inherently prevents it from working with large-sector drives, and in fact I recently received a 3TB USB drive from WD that actually shows a sector size of 4,096 bytes and has an MBR. I realize that USB mass storage drivers already had to deal with large-sector devices, so that's a different issue, but it works fine with an MBR. — Preceding unsigned comment added by Linush100 (talk • contribs) 01:46, 17 August 2012 (UTC) [5]Reply

The term "NEWLDR" is mentioned various times in this article... but i never seen before. It's a wikipedia invention? (u can check a lot of analysis on http://thestarman.pcministry.com/ and NEWLDR never apperas.. ) 78.134.44.120 (talk) 23:50, 3 February 2013 (UTC)Reply

That's a group of MBRs used in various single- and multi-user operating systems of Digital Research / Novell origin (like FlexOS, Multiuser DOS, System Manager, REAL/32, PalmDOS, Novell DOS, OpenDOS, DR-DOS, etc.). It normally gets installed by a multi-boot command line utility named LOADER provided with these operating systems, and is also the default MBR used in some versions of FDISK. All these MBRs can be identified by their "NEWLDR" signature, hence the name. By default, they work just like a MS-DOS/PC DOS MBR, but if configured accordingly they will try to load a special boot image or file before they fall back to use the normal method of loading the boot sector of the active partition. This external boot file will typically bring up a configurable multi OS selection screen, supporting a dozen different operating systems, including MS-DOS, PC DOS, OS/2, Windows NT, etc., but some operating systems (f.e. REAL/32 and DR-DOS) can use this also for other purposes. --Matthiaspaul (talk) 05:01, 4 February 2013 (UTC)Reply

interesting, thanks. Actually doing some more specific research with "DR-DOS", i've seen that it's truly used as an enhanced MBR form, in DR-DOS 7.x ...(for example). Surely a bit obscure option, anyway it's weird that is so poorly documented in internet, despite the tons of stuff about MBR and Bios 0000:7C00 bootstrap. 78.134.44.120 (talk) 17:45, 4 February 2013 (UTC)Reply

Is it possible to use MBR in pretty standard way with 2 or 3 partitions each less than 2TB or 2.1TB in order to use 3+TB hard drives with full capacity???

I need an answer. I do not need one big partition.
I need the answer to the question of high backward compatibility.

I would suppose it should be possible to use 4 partitions 2.1TB each and 8.4TB harddrive with MBR.
But I am not sure.

And I would like that article would give such clear and simple answer.

-- IP 95.108.105.3 at 2013-07-08T14:33:44‎

Hi, if you want a clear and simple answer, the answer is: No.

There are several tricks to slightly raise the 2 TB limit, but they are all non-standard and unless you know exactly what you and your operating system(s) are doing, you should better not try to use them, as they will cause numerous compatibility problems and impose a high risk of serious data corruption.

• The entries in the MBR are 32 bit wide, therefore you can only address sectors up to this limit. 2^32 * 512 = 2 TB. If you increase the sector size (f.e. to 4 KB), you can change this to 2^32 * 4096 = 16 TB, however, many (most!) older tools, operating systems and chipsets will not support sector sizes other than 512 bytes/sector, and unless they are specifically written to support variable sector sizes (which 99% of them are not, simply because originally there was no method to even retrieve the actual sector size supported by the system, so that they are hardwired to assume 512 bytes/sector) continuing to use the same code for 4 KB sectors will almost certainly cause memory to become overwritten (as the memory allocated for sector buffers will be 512 bytes / sector).
• You could attempt to define one partition occupying almost 2 TB and another starting just below the 2 TB barrier (so that its start can still be specified in the MBR) with a size of 2 TB as well (so that the size can still be expressed in the MBR as well). (This does not work with more than two partitions, because any further partition would still have to start within the first 2 TB of the disk, and this is impossible to achieve because the space is already occupied by the former partitions -- partitions must never overlap. So, utilizing this trick, you could get at most ca. 4 TB with 512 bytes per sector or ca. 32 TB with 4 KB sectors, and to express the highest sector addresses, you would need 33 bits.) However, this will only work, if all the code involved fully supports LBA-48. Most older systems and tools, however, even if they claim to support LBA-48, will use 32-bit arithmetics internally, and therefore any addresses of the second partition which overlap the 2 TB barrier (that is, when the 33rd bit, which does not exist in 32-bit arithmetics, would have to become set) would be folded back to the start of the disk causing serious data corruption. Most boot sectors use 32-bit arithmetics as well. To sum it up, while the MBR entries could be massaged to describe partitions up to 4 TB (with 512 bytes per sector), for this to work, the code, which interprets the MBR entries, needs to take more than 32 bits into account as well -- and most existing code dealing with MBR partitions in one way or another does not, simply because, officially, the MBR maxes out at 32 bit, not 33 bit.
• A third method, and while non-standard IMO the only one, which has some merits, is to combine MBR partitioning with GPT partitioning. This requires using a hybrid MBR, where the first 2 TB of the disk are occupied by MBR partitions, located inside a GPT container (so that GPT-aware operating systems do not modify them), and the remainder of the disk used up by other GPT partitions. The idea is that MBR-aware systems will only see the MBR partitions and totally ignore the higher GPT ones, whereas GPT-aware OSes will see both, but only use the GPT partitions and never touch the MBR partitions. Therefore, peaceful coexistance can be achieved, although resizing or moving partitions at a later stage can be very dangerous, as the MBR and GPT partition tables have to be kept in synchronization and additional restrictions have to be taken into account.

Several approaches, how to achieve that, exists (but the "optimal solution" is still an area of research and development), and while you still need to be cautious because the official standard does not allow this, "better" GPT partitioning tools are able to cope with these scenarios at least to some extent.

• A fourth method would be to write a disk BIOS overlay and special drivers for operating systems using MBR partitions so that they could mount GPT partitions as well (for as long as they are smaller than 2 TB each). The idea here is that the operating system will never see the physical location of the volume but just use a logical volume (or a virtual physical disk) with LBA sector addresses below 2 TB (thereby usable with 32-bit arithmetics), and the driver/overlay will translate these virtual addresses into the real physical addresses. This would be a relatively easy task for real-mode-based operating systems like DOS (because it would only have to intercept disk BIOS INT 13h, although the overlay would probably have to utilize RPL/RPLOADER relocation methods as well), but more difficult for protected mode OSes.

--Matthiaspaul (talk) 13:23, 8 July 2013 (UTC)Reply

@Matthiaspaul: Hello there! Regarding this edit, how are those 10-bit values, when the table states their total length is one byte each? -- Dsimic (talk) 22:57, 14 November 2013 (UTC)Reply

Ah, got it. Everything is perfectly fine. -- Dsimic (talk) 14:24, 15 November 2013 (UTC)Reply

I noticed in the introduction of this article that this claim is made: "The organization of the partition table in the MBR limits the maximum addressable storage space of a 512-sector disk to 3.99 TiB (2³² × 512 +2³² × 512 bytes)." However, everything I've read indicates that the max size is actually about 2 TB (2³² x 512) and it says as much in the GUID Partition Table wikipedia page ("For hard disks with 512-byte sectors, the MBR partition table entries allow up to a maximum of 2 TiB (2³² × 512 bytes)"). I also couldn't find any reference to 3.99 TiB in the relevant reference (https://support.microsoft.com/en-us/kb/2581408), and actually only saw 2.2 TB mentioned there. I'm wondering if this is an error and it should actually be 2 TB instead of 3.99 TiB. I don't understand where the extra 2³² x 512 comes from. Could anyone verify that this is an error or otherwise explain why it's 3.99 TiB? Thanks! Sevske (talk) 17:22, 10 March 2016 (UTC)Reply

The value was written as 2 TB up until this edit on 2015-11-10 by @Jimmi Hugh: who perhaps might chime in. The edit summary for that edit was Reference or not, basic maths extrapolated from the article trumps some claim by Microsoft... so perhaps he was relying on something else within the article, possibly not there anymore. —EncMstr (talk) 02:17, 11 March 2016 (UTC)Reply

2 TB is the correct number here. A similar question was answered by me in detail further up in Talk:Master boot record#3 TB or 4 TB MBR Multi-Partition Compatibility.

While I think it is important to mention any non-standard usage as well, so that partitioning software and newer operating systems or disk drivers will get a chance to (actively or passively) deal with it, it is also important to note that such usage is non-standard and may cause data corruption or will break existing tools and operating systems.

The MBR concept was introduced with DOS more than 3 decades ago (and is used by modern DOS versions up to the present), so anything that would break even older versions of DOS must be considered as non-standard and requires to be specially mentioned, not shown as default in the article, a principle maintained by previous article editors.

So, just changing some of the maximum numbers in the text beyond the standard values "because we can" will cause considerable confusion among readers. I have therefore changed back the value. The non-standard use is already discussed further down in the article, where it is properly marked with cautionary notes.

--Matthiaspaul (talk) 09:50, 3 May 2016 (UTC)Reply

Going by this logic, wouldn't we need to decrease the maximum size to 8.4 GB? After all, using more of the disk requires LBA, which also breaks compatibility with old versions of MS-DOS. beforeAdapter (talk · contribs) 2022-03-18T21:49:30Z

I can't help to notice that the partition entry section describes a table with 3 byte values (24-bit) per address, so this seems to be the situation with LBA 24-bit. If I am not mistaken, for LBA 48-bit 6 byte addresses (48-bit) would be required. So this section seems to be missing an explanation for the situation with LBA-48. I am not really qualified in this area, so I would prefer if someone more knowledgeable would add this information, if possible. Tony Mach (talk) 15:19, 25 March 2016 (UTC)Reply

ATA 28 bits (C:16: 1..65536 H:4 1..16, S:8 1..255) fit as LBA in 4 bytes, the old INT13h CHS (24 = C:10 + H:8 + S:6) can get the well-known dummy 1023 255 63. But as you say, more than 2^32-1 doesn't fit into a traditional MBR, for that you'd use GPT-format (with a dummy protective EFI partition in a dummy MBR).

Quick check: 2*24bits CHS (start+end) are 6 bytes, boot flag 1 byte, partition id 1 byte, LBA start 32bits + LBA count 32 bits are 8 bytes, 6+1+1+8=16 for one partition table entry.

Be..anyone (talk) 06:47, 7 April 2016 (UTC)Reply

0040hex:0013hex is even more obscure than 0040h:0013h, how about 0040:0013? Maybe in a Template:SegOfs to simplify further bulk updates of this page. Be careful with INT 13h, that h is not really optional, unless you test 0x13. –Be..anyone (talk) 04:57, 9 April 2016 (UTC)Reply

As we're dealing with hex numbers, not specifying the base would be ambiguous and would cause confusion.

Appending a lower-case "h" is hardly obscure, for it is the format used to denote hex numbers in the majority of printed literature dealing with the subject -- and has been for decades. It is also a very common format for hex numbers in other contexts. This is why I prefer this format.

A few (newer) publications use the "0x" prefix notation, however, "0x" is C-syntax, and I find it odd (and distractingly nerdy) to use the syntax of a programming language in an encyclopedic text not even remotely related to C or similar programming languages (non-programmers really have difficulties figuring out what that strange "0x" might mean, in particular as the "x" may also indicate don't care bits). Also, the "0x" notation isn't normally combined with the offset notation using a "+" prefix (which, in conjunction with hex numbers, I have only seen being used with postfixes) nor is it normally used with 3-digit hex values (we are using in the article to hint the width of some values).

I'm also happy with a subscripted "_h" suffix. In my opinion, the "_hex" suffix EncMstr has implemented for testage purposes is overly long, but it is still better than "0x".

--Matthiaspaul (talk) 19:03, 3 May 2016 (UTC)Reply

@Matthiaspaul: I thought the mixed use of hex which you just reverted was one of the stronger uses of notation so far. While it was not "consistent", I felt it was more intuitive. A column of numbers labeled hex has diminished need for a subscript and it certainly seemed cleaner. Numbers less than ten also don't suffer from ambiguity, though there is a lot of tradition in the "trade" to write 00000000000000000000h (for example) instead of simply 0. Thoughts? —EncMstr (talk) 07:57, 4 May 2016 (UTC)Reply

Hi EncMstr. I see your point, but I think in an article dealing with a "delicate" subject such as this one, it is very important to avoid any possible misinterpretation. While for us it may be completely obvious (or can be deduced from context) which values are meant as hexadecimal and which as decimal, it may totally confuse less experienced readers if they see hex and decimal numbers mixed (and sometimes even intermixed with similar looking strings), or find different notations for hex numbers in different sections of an article. That's why I think a consistent format throughout the article is paramount. You are right that specifically denoting "hex" is redundant in a table column labeled "Hex", but if we would omit the "hex" there, it would create inconsistency with the notation used elsewhere in the article - IMO the local benefit in these table columns isn't worth giving up consistency as a whole.

Regarding leading zeros. I see that point as well, but - as you know - leading zeros are often used as a visual clue to indicate (or at least give a hint on) the underlying bitwidth of some values in machine representation. That's why we use f.e. 3 hex digits in sector offsets, 4:4 hex digits in segment:offset memory addresses, or 6 hex digits for entries spanning 3 bytes. While this common notation introduces some slight form of redundancy if the width is specified elsewhere already, it is very intuitive and thereby helps understanding.

I'm open in regard to the actual hex notation used, but it should be consistent. My order of preference would be: "h" postfix, "_h" postfix, "_hex" postfix. The "0x" prefix notation would be too "nerdy" for my taste (and also incompatible with the offset notation), and "₁₆" postfix appears to be unnecessarily mathematically to me.

--Matthiaspaul (talk) 09:20, 4 May 2016 (UTC)Reply

Hello fellow Wikipedians,

I have just modified 2 external links on Master boot record. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.yale.edu/pclt/BOOT/PARTITIO.HTM
• Added archive https://web.archive.org/web/20070510140812/http://mirror.href.com/thestarman/asm/mbr/index.html to http://mirror.href.com/thestarman/asm/mbr/index.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:26, 21 January 2018 (UTC)Reply

Apokrif (talk) 21:05, 25 April 2024 (UTC)Reply