PDF de programación - HDs grandes: mini-como

HDs grandes: mini-COMO

Andries Brouwer, [email protected]
Traducción: Fco. J. Montilla, [email protected]

v1.0, 960626

Todo lo referente a geometrías de disco duro, así como el límite de las BIOS/SO relacionados con particio-
nes más allá de los 1024 cilindros.

Índice General

1 El Problema

2 Arrancando

3 Geometría de los discos y particiones.

4 Traslaciones y Managers de disco

5 Traslación de disco al núcleo en discos IDE.

5.1 EZD . . . . . .

.

. . . .

5.2 DM6:DDO . .

. . . . .

5.3 DM6:AUX . .

. . . . .

5.4 DM6:MBR . .

. . . . .

5.5 PTBL . . . . .

. . .

. .

.

.

.

.

.

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

.

.

.

.

.

. . .

. . .

. . .

. . .

. . .

.

.

.

.

.

.

.

.

.

.

. . .

. . .

. . .

. . .

. . .

.

.

.

.

.

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

.

.

.

.

.

. .

. .

. .

. .

. .

. .

. .

. .

. .

. .

.

.

.

.

.

.

.

.

. . .

. . .

. . .

.

.

.

6 Consecuencias

6.1 Detalles IDE .

. . . . .

. .

. .

. .

. .

.

. .

. .

. . .

.

6.2 Detalles SCSI .

. . . . .

. . .

. .

.

. . .

.

.

. .

.

. . .

.

.

. . .

.

.

. . .

.

.

. . .

.

.

. . .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

7 Anexo: El INSFLUG

1 El Problema

1

2

2

3

4

4

4

4

4

5

5

5

6

8

Suponga que tiene un disco duro con más de 1024 cilindros. Suponga que encima emplea un sistema operativo que
hace uso de la BIOS. Si es así, entonces tiene un problema, ya que el habitual interfaz de la BIOS a operaciones de
E/S con discos, la INT13, usa un campo de 10 bits para el cilindro en el que se produce una operación de E/S, por lo
que cilindros más allá del 1024 resultarán inaccesibles.

Afortunadamente, Linux no hace uso de la BIOS, por lo que no resulta un problema.

Bueno, a excepción de dos aspectos:

1. Cuando arranca el sistema, Linux no está ejecutándose todavía, y por tanto, no puede ahorrarle los problemas
relacionados con la BIOS. Esto acarrea ciertas consecuencias para con LILO y gestores de arranque similares.

2. Arrancando

2

2. Es necesario, para todos los sistemas operativos que compartan un disco el coincidir en dónde están las
particiones. En otras palabras, si usa Linux, y por ejemplo, Dos en un disco, ambos deberán interpretar la tabla
de particiones del mismo modo. Esto resulta en determinadas consecuencias con el núcleo de Linux y fdisk.

Lo que sigue es una descripción bastante detallada de todos los detalles relevantes. Téngase en cuenta que empleé el
kernel 2.0.8 como fuente de referencias; para otras versiones la cosa puede variar ligeramente.

2 Arrancando

Cuando el sistema arranca, la BIOS lee el sector 0 (conocido como MBR, Master Boot Record, o Registro de Arran-
que Principal) del primer disco (o de un floppy), y salta al código allí residente –algún tipo cargador bootstrap1,
generalmente–.

Los pequeños programas de bootstrap que allí se encuentran no poseen controladores de disco propios, típicamente,
y emplean servicios de la BIOS para ello. Esto significa que el núcleo de Linux sólo puede arrancar cuando reside
enteramente antes de los primeros 1024 cilindros.

Este problema se puede resolver fácilmente, asegurándose de que el núcleo (y quizás otros ficheros empleados durante
la fase de arranque, como los ficheros de mapeo de LILO) residen en una partición que se encuentra en su totalidad en
los primeros 1024 cilindros de un disco al que la BIOS puede acceder –esto significa que probablemente sea el primer
o segundo disco–.

Otro punto a considerar es que tanto el cargador de arranque y la BIOS deben asentir en cuanto a la geometría del
disco. Podría ser útil dar a LILO la opción ‘linear’. Más sobre esto a continuación.

3 Geometría de los discos y particiones.

Si tiene varios sistemas operativos en sus discos, cada uno puede estar utilizando una o varias particiones. El más
mínimo desacuerdo en cuanto a dónde están dichas particiones puede acarrear catastróficas consecuencias.

El MBR contiene una tabla de particiones describiendo donde están las particiones (primarias). Hay 4 entradas en
dicha tabla, para 4 particiones primarias2, y cada una tiene el siguiente aspecto:

struct partition {

/* 0x80: arrancable, 0: no arrancable */

char active;
char begin[3]; /* CHS para el primer sector */
char type;
char end[3];
int start;
int length;

/* CHS para el ultimo sector */
/* numero de sector en 32 bit (contado desde 0) */
/* numero de sectores 32 en bit */

};

(donde CHS se refiere a Cilindros/Cabezas/Sectores).

Por tanto, la información es redundante: la localización de la partición se da tanto por los campos de 24 bits begin y
end, como por los campos de 32 bits start y length.

Linux sólo usa los campos start y length, y puede por tanto manejar particiones no mayores de 2ˆ32 sectores, o
lo que es lo mismo, particiones de más de 2 TeraBytes. Lo cual es doscientas veces el tamaño de los discos disponibles
actualmente, por lo que será suficiente para los próximos 10 años o así.

1N del T: El término bootstrap procede de la expresión anglosajona “To pull oneself up by one’s bootstraps ”, que viene a

significar “rehacerse por sí sólo, por sus propios medios, o por méritos propios, etc”

2N del T: o para 3 primarias y 1 extendida

4. Traslaciones y Managers de disco

3

Desafortunadamente, la llamada a la INT13 de la BIOS emplea los CHS codificados en tres bytes, con 10 bits para el
número de cilindro, 8 para el número de cabeza, y 6 para el numero de sector de pista.

Los números posibles de cilindro son 0-1023, de cabeza 0-255, y de sector de pista 1-63 (sí, los sectores de una pista
se cuentan desde 1, no desde 0). Con esos 24 bits se puede acceder a 8455716864 bytes (7.875 GB), doscientas veces
más de las capacidades de disco disponibles en 1983.

Todavía más desafortunadamente, los interfaces IDE estándar permiten 256 sectores/pista, 65536 cilindros y 16 cabe-
zas. Esto por sí mismo permite el acceso a 2ˆ37 = 137438953472 bytes (128 GB), pero combinado con la restricción
de la BIOS a 63 sectores y 1024 cilindros hace que sólo queden 528482304 bytes (504 MB) accesibles.

Esto no es suficiente para los discos de hoy en día, por lo que la gente recurre a todo tipo de triquiñuelas, tanto vía
hardware como software.

4 Traslaciones y Managers de disco

A nadie le importa cuál es la geometría ‘real’ de un disco. De hecho, incluso el número de sectores por pista es
variable –hay más sectores por pista conforme nos acercamos al borde exterior del disco– por lo que no hay un
número de sectores por pista ‘verdadero’.

Para el usuario resulta más conveniente considerar un disco como una simple serie3 lineal de sectores numerados como
0, 1, ..., y dejar a la controladora el trabajo de encontrar en qué lugar del disco reside un sector dado.

Esta numeración lineal se conoce como LBA. Las direcciones lineales correspondientes a (c,h,s)4para un disco con
geometría (C,H,S)5 corresponden a c*H*S + h*S + (s-1). Todas las controladoras SCSI “hablan” LBA, junto con
algunas IDE.

Si la BIOS convierte los (c,h,s) de 24 bits a LBA y le pasa eso a una controladora que “entienda” LBA, entonces
vuelven a ser accesibles 7.875 GB. No es suficiente para todos los discos, pero no deja de ser constituir una mejora.

Téngase en cuenta que que aquí CHS, tal y como los usa la BIOS, no tiene nada que ver con la ‘realidad’.

Algo similar funciona cuando la controladora no “habla” LBA, pero la BIOS sí sabe hacer la traslación. (En el setup
esto se suele indicar como “large”.) La BIOS presentará una geometría (C’,H’,S’) al sistema operativo, usando (C,H,S)
para hablar con la controladora del disco. Normalmente S = S 0 ; C 0
= H  N , donde N es la menor
potencia de dos que asegura que C’ <= 1024 (a fin de que se malgaste la menor capacidad posible al redondear en C’
= C/N). Nuevamente, esto nos proporciona acceso a 7.875 GB.

= C=N y H 0

Si la BIOS no sabe nada acerca de ‘LBA’ o ‘Large’, podemos recurrir a ciertas soluciones software. Los Disk Managers
o Gestores de Disco como OnTrack o EZ-Drive reemplazan las rutinas de gestión de disco por otras suyas. Esto se
lleva a cabo normalmente haciendo residir el código del gestor de disco en el MBR y sectores subsecuentes (OnTrack
llama a este código DDO: Dynamic Drive Overlay6, de modo que sea arrancado antes que cualquier otro sistema
operativo. Esa es la razón por la que se pueden tener problemas arrancando desde disquete cuando se ha instalado un
Gestor de Disco.7

El efecto es más o menos el mismo que cuando se hacen traslaciones vía BIOS, pero –especialmente cuando haya
distintos sistemas operativos en el mismo disco– con la salvedad de que pueden causar bastantes problemas.

Linux soporta OnTrack Disk Manager desde la versión de núcleo 1.3.14, y EZ-Drive desde la versión 1.3.29. Más
detalles a continuación.

3N del T: “array” en el original.
4N del T: c=cilindros h=cabezas s=sectores; parámetros lógicos.
5N del T: parámetros físicos
6N del T: algo así como Superposición Dinámica de Disco.
7N. del T. Esto no significa que no pueda hacerse de modo seguro; los gestores suelen proveer utilidades para hacer disquetes

especiales de arranque

5. Traslación de disco al núcleo en discos IDE.

4

5 Traslación de disco al núcleo en discos IDE.

Si el núcleo de Linux detecta la presencia de algún gestor de disco en un disco IDE, tratará de remapear el disco del
mismo modo en que lo haya hecho el gestor de disco, de modo que Linux ‘vea’ el mismo particionamiento del mismo
que bajo DOS con OnTrack o EZ-Drive.

No obstante, NO se produce remapeo alguno cuando se especifica la geometría en la línea de comandos8, por lo
que una opción como ‘hd=cyls,heads,sec