área en el disco después del MBR y antes del punto de inicio de la partición

10

Si uso un esquema de partición MBR y creo una partición primaria o extendida con fdisk(versión 2.20.1), entonces comienza en el sector 2048. Si no recuerdo mal, las versiones anteriores de fdiskcomenzaron la primera partición en el sector 63. Si MBR solo necesita 512 bytes, entonces ¿por qué la primera partición no comienza en el sector 2? ¿Qué se mantiene en esos 2047 sectores? ¿Alguna etapa del gestor de arranque?

partition mbr

— Martín
fuente

Para su información, la alineación de 1 MiB (sector 2048) se introdujo en Linux fdisken la util-linux-ng-2.17.1/fdisk/fdisk.cfunción update_sector_offset(void), lanzada el 22-02-2010. Windows Vista fue lanzado en 2006-11.

— pts

Preguntas y respuestas relacionadas: superuser.com/q/352572/19956 , superuser.com/q/565577/19956 .

— pts

16

La antigua brecha de 32 KB entre MBR y el primer sector del sistema de archivos se denomina región de compatibilidad de DOS o brecha de MBR, porque DOS requería que las particiones comenzaran en los límites del cilindro (y cada cilindro tenía 64 sectores, es decir, 64 sectores * 512 bytes / sector = 32 KB de espacio) .

ingrese la descripción de la imagen aquí

Legacy GRUB (GRUB1) podría haberlo usado para instalar el gestor de arranque GRUB1 de 1.5 etapas allí: http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation .

Enlaces adicionales:

— Boris Burkov
fuente

1

Ok, gracias por explicar esto! Parece que GRUB2 usa la misma área entre el MBR y antes de la partición para su código de arranque. Según grub-install -vtengo instalado GRUB2 y si ejecuto dd if=/dev/sda obs=1 ibs=1 skip=512 count=2047 2>/dev/null | strings -n4, hay "cargando", "Geom", "Leer", "Error" en esta área y deberían pertenecer a GRUB2.

— Martin

@ Martin Hm, observación interesante. Solo tengo "^ @" s allí, grub2, también. Parece que mi etapa 2 está justo en el sistema de archivos. :)

— Boris Burkov

1

@ Martin: Si anteriormente tenía GRUB 0.99 instalado, aún podría estar en esa área, incluso si su gestor de arranque actual es GRUB 2.xy no lo está utilizando.

— Ben Voigt

6

Esta es una optimización del rendimiento y no está relacionada con Linux en absoluto, solo con el hardware. Los discos modernos (llamados discos "4K") utilizan sectores físicos de 4096 bytes en lugar de 512. Todavía puede abordar sectores individuales de 512 bytes, pero eso puede afectar gravemente el rendimiento si las particiones (o más bien: sistemas de archivos) no están alineados a 4K .

Iniciar el sector 64 sería suficiente para este requisito. El aumento a 2048 parece ser preventivo (por ejemplo, permitir colocar una partición de arranque UEFI allí si el disco debe convertirse a GPT más adelante).

— Hauke Laging
fuente

Por optimización del rendimiento, quiere decir que si el sistema de archivos comienza en el medio del sector 4K, entonces todos los datos dentro de este sistema de archivos también están desalineados y esto significaría que si uno cambia incluso un byte en un archivo en el sistema de archivos, entonces dos sectores físicos 4K deben ser leídos y modificados? Si el sistema de archivos está alineado, ¿entonces solo se necesita modificar un sector 4K siempre y cuando todos los bytes estén en el mismo sector físico 4K?

— Martin

2

@Martin El problema es que el kernel siempre escribe bloques 4K (tamaño de página) en el disco (porque las páginas están en caché). A diferencia de un solo sector, una página 4K puede ser parte de dos sectores. En ese caso, no se deben escribir 4K sino 8K. Y aún peor: puede ser que uno o incluso ambos bloques 4K en el disco se deban leer primero.

— Hauke Laging