Talk:Master boot record

message: 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)
replies: text: 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)
thread_title:  Partition alignment 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Merge proposals 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
thread_title:  Partition size for 512e Advanced Format 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  NEWLDR? 

message: 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)
thread_title:  3 TB or 4 TB MBR Multi-Partition Compatibility 

message: 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)
replies: text: Ah, got it.  Everything is perfectly fine. -- Dsimic (talk) 14:24, 15 November 2013 (UTC)
thread_title:  Partition table entries table 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 05:26, 21 January 2018 (UTC)
thread_title:  External links modified (January 2018) 

message: Apokrif (talk) 21:05, 25 April 2024 (UTC)
thread_title:  Should "disc's sectors" or "blocks" be wikified to [[Disk sector]] or [[Block (data storage)]]?