area sul disco dopo l'MBR e prima del punto iniziale della partizione


10

Se utilizzo uno schema di partizionamento MBR e creo una partizione primaria o estesa con fdisk(versione 2.20.1), inizia sul settore 2048. Se ricordo bene, le versioni precedenti di fdiskavviavano la prima partizione sul settore 63. Se MBR necessita solo di 512 byte, quindi perché la prima partizione non si avvia nel settore 2? Cosa si conserva in quei 2047 settori? Qualche fase del bootloader?


A proposito, l'allineamento di 1 MiB (settore 2048) è stato introdotto in Linux fdiskin util-linux-ng-2.17.1/fdisk/fdisk.c, funzione update_sector_offset(void), rilasciato il 22-02-2010. Windows Vista è stato rilasciato nel 2006-11.
punti

Risposte:


16

Il vecchio gap di 32 KiB tra MBR e il primo settore del file system è chiamato regione di compatibilità DOS o gap di MBR, poiché DOS richiedeva che le partizioni iniziassero ai confini del cilindro (e ogni cilindro avesse 64 settori cioè 64 settori * 512 byte / settore = 32 KiB spazio) .

inserisci qui la descrizione dell'immagine

Legacy GRUB (GRUB1) avrebbe potuto usarlo per installare il bootloader GRUB1 1.5 stage lì: http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation .

Link aggiuntivi:

  1. http://www.pixelbeat.org/docs/disk/
  2. /superuser/107235/how-do-boot-sectors-and-multiple-drives-works/108152#108152
  3. http://www.dedoimedo.com/computers/grub.html

1
Ok, grazie per averlo spiegato! Sembra che GRUB2 usi la stessa area tra l'MBR e prima della partizione per il suo codice di avvio. Secondo grub-install -vme ho installato GRUB2 e se lo eseguo dd if=/dev/sda obs=1 ibs=1 skip=512 count=2047 2>/dev/null | strings -n4ci sono "caricamento", "Geom", "Leggi", "Errore" in quest'area e dovrebbero appartenere a GRUB2.
Martin

@Martin Hm, osservazione interessante. Ho solo "^ @", anche grub2. Sembra che il mio stadio 2 sia proprio nel file system. :)
Boris Burkov il

1
@Martin: se in precedenza avevi installato GRUB 0.99, potrebbe essere ancora in quell'area, anche se il tuo bootloader attuale è GRUB 2.x e non lo utilizza.
Ben Voigt,

6

Questa è un'ottimizzazione delle prestazioni e non è affatto correlata a Linux, ma solo all'hardware. I dischi moderni (i cosiddetti dischi "4K") utilizzano settori fisici di 4096 byte anziché 512. È comunque possibile indirizzare singoli settori a 512 byte ma ciò potrebbe influire negativamente sulle prestazioni se le partizioni (o meglio: file system) non sono allineate a 4K .

L'inizio del settore 64 sarebbe sufficiente per questo requisito. L'aumento al 2048 sembra essere preventivo (ad esempio consentire di inserire lì una partizione di avvio UEFI se il disco dovesse essere convertito in GPT in seguito).


Per ottimizzazione delle prestazioni intendi che se il file system si avvia nel mezzo del settore 4K, anche tutti i dati all'interno di questo file system sono disallineati e ciò significherebbe che se si modifica anche un byte in un file sul file system, allora due settori fisici 4K devono essere letti e modificati? Se il file system è allineato, è necessario modificare solo un settore 4K purché tutti i byte si trovino nello stesso settore fisico 4K?
Martin

2
@Martin Il problema è che il kernel scrive sempre blocchi 4K (dimensioni della pagina) sul disco (perché le pagine sono memorizzate nella cache). A differenza di un singolo settore, una pagina 4K può far parte di due settori. In tal caso non è necessario scrivere 4K ma 8K. E ancora peggio: è possibile che uno o entrambi i blocchi 4K sul disco debbano essere letti per primi.
Hauke ​​Laging,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.