Volver a la portada de Duiops
Volver al Web de Duiops
 
   
Google
 
En Internet En duiops.net
Menú
Secciones destacadas
Artículos y FAQs
Trucos de Windows
Versiones de Windows
y suites de software
Windows Vista
Windows Media Center
Windows XP
Windows 2000
Windows Millenium
Windows 98/98 SE
Windows 95 OSR-2
Internet Explorer
Office
Otros
Tutorial muy básico
   
Portada

 

Apúntate a la lista de correo del Web de Duiops

Portada - Artículos y FAQs - Grabación de datos en un disco duro
 
Grabación de datos en un disco duro

 

Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98

GRABACION DE DATOS EN UN DISCO DURO
------------------------------------

En un articulo mio anterior sobre los discos IDE, introduje la problematica de como se graban fisicamente los datos en la superficie del disco. Repasemos un poco.....

PROBLEMATICA
------------

La problematica es la siguiente, las informaciones se guardan en la superficie de un disco duro, bien, en principio hemos de olvidar que se guardan en representacion binaria.

No se pueden guardar "unos" y "ceros" con ayuda de particulas "magnetizables", ya que en ese caso, se habrían de reflejar los dos estados "magnetizado" y "no magnetizado" para los valores 0 y 1. Pero precisamente esto no es posible, tal y como introducimos a continuacion.

Si se siguiera la propuesta anterior, la secuencia de ceros y unos apareceria como secuencia de particulas magnetizadas y no magnetizadas. Pero con ello el cabezal de lectura del disco no podría distinguir las diferentes particulas magnetizadas de esta secuencia. Así no se sabría si estamos tratando con 6 o con 9 ceros, por ejemplo.

En esta situación, solo nos serviría de ayuda si el cabezal de lectura supiese la "longitud" de una particula magnetica, pudiendo poner entonces el tiempo transcurrido entre una particula y otra en funcion de la cantidad de particulas magneticas y con ello la relacion de los bits. Así, se necesita una especie de "pulso" de reloj que con cada impulso indique que ha llegado el tiempo de un nuevo bit.

Pero el tiempo constante, que se necesita para la creación de un pulso, no se puede determinar con exactitud a causa de diferentes factores. La culpa la tiene por ejemplo la velocidad de rotacion de un disco duro, que dentro de ciertos limites, siempre varía, así como el hecho de que nunca se puede magnetizar una unica particula magnetica, sino siempre todo un grupo cuyo numero no siempre es constante.

Bonito problema ¿no?. ¿como podemos hacer entonces, o como se las arregla el disco duro para guardar y ser capaz de recuperar?

PRODECIMIENTOS
--------------

1) EL PROCEDIMIENTO FM y MFM

Estos son procedimiento antiguos que ya no se utilizan y por tanto vamos a prescindir de ellos. Precisamente en los discos grabados con estos procedimientos, eran en los que podiamos formatear con ayuda de la bios a bajo nivel sin problemas. No se debe hacer esto nunca en los discos actuales.

2) PROCEDIMIENTO RLL

El problema fundamentel, era que si se escribian muchos unos seguidos o muchos ceros seguidos (unos y ceros binarios), y cada uno de ellos se grababa como un cambio de flujo magnetico, la electronica del disco era incapaz de saber "cuantos" habian sido grabados ya que por muy exacta que fuese la electronica, existe un motor mecanico que hace girar al disco. Entonces, ¿si no se "ve" cambios de flujo en 1 milisegundo por ejemplo, cuantos ceros corresponden a esto?....... 1500 o 1501... un minimo error del giro del motor, llevaria a entender mas o menos ceros de los que realmente se quisieron grabar.

El procedimiento RLL (Run Length Limited) proyecta las secuencias de bits que queremos grabar a otro codigo que es el que se guarda.

El nuevo codig guardado, debe cumplir que por muchos unos seguidos que existan (o muchos ceros) deben existir los correspondientes cambios deflujo, sin que se "amontonen" demasiado.

Se pueden pensar en infinitos patrones de codigos, segun los grande que sea el numero maximo de ceros consecutivos y lo pequeño que sea su numero minimo. Se utilizan dos metodos que se denomina RLL 2,7 y RLL 3,9

RLL 2,7 es el metodo estandar. Este quiere decir que entre dos unos aparecen en este caso un minimo de dos y un maximo de 7 ceros.

Veamos la table de conversion:

Patron de bits a guardar        Codigo
------------------------                   ------
      000                                   000100
      10                                     0100
      010                                   100100
      0010                                00100100
      11                                    1000
      011                                  0010000
      001                                  00001000

A la vista del cisco mostrado en dicha tabla, vemos que ciertos "Byte" como por ejemplo el 00000001b no se pueden transformar a primera vista. Y no debemos olvidar que a este nivel se trabaja con sectores y no con bytes individuales. Por ello, tambien un byte como 00000001b se puede transformar utilizando los bits de los siguientes Bytes del sector.

Solo sería problematica entonces, la codificacion del ultimo byte de un sector, ya qie para entonces, el codigo anterior debe funcionar, puesto que no hay mas bytes que grabar en dicho sector. Pero en la practica este problema se resuelve de la siguiente manera: la controladora añade un byte extra adecuado. Los bits superfluos se vuelven a cortar luego en la lectura y con ello el ultimo byte del sector se devuelve correctamente.

FACTOR DE INTERCALADO (Interleave)
----------------------------------

Hoy en dia las controladoras se han convertido en tan rapidas, que se pueden permitir en un acceso en lectura a un sector, el leer de paso toda la pista aunque el programa no se lo haya pedido. Y se los guarda en un buffer (memoria intermedia) interno. De esta manera si el programa vuelve a pedir el siguiente sector (lo cual es muy probable), se lo dará inmediatamente. Decimos que es muy probable, porque recordad que a nivel logico, se almacanenan "cluster", de 4, 8, 16, 32 Kbs dependiendo de como esté particionado nuestro disco. Por tanto, NUNCA le llegará la peticion de un sector a la controladora, sino que a continuacion le pedirá el siguiente sector y así al menos, hasta completar el tamamño del cluster.

Antiguamente, la electronica de decodificacion era lenta. Por tanto cuando acababa de leer un sector del disco, empeaba la decodificacion para dejarlo en el buffer intermedio. Por tanto para leer el siguiente sector del disco, habia que esperar a que el disco diese una vuelta completa para que ese siguiente sector pasase otra vez debajo de la cabeza de lectura.

Para evitar estas perdidas de tiempo, a "alguien" se le ocurrio el factor de interleave. Es decir imaginemos que los sectores 1, 2, 3, 4, 5..... así hasta los 32 "supongamos" de una posible pista, en vez de numerarse así, consecutivamente, se numeraban: 1,16,2,17,3,18,4,19.... (es decir, se "intercalaba" media pista en la otra media. De esta manera despues de leer el sector numero "1", mientras pasaba por el 16, le daba tiempo a la electronica a decodificar y dejar en el buffer, terminaba de pasar el 16 y ya podia leer el 2 porque se lo encontraba justo en ese momento...... etc. Esto es lo que se le llamo facto de Interleave 1:2. Evidentemente, dependiendo del disco, existian factores 1:2, 1:3, ... etc. Y habia que prestar mucha atencion cuando se formateaba a bajo nivel, a este tipo de factores ya que se especificaba en el formateo a bajo nivel y el rendimiento del disco variaba brutalmente de como estaba esto definido.

Hoy es dia, esto no es necesario. Los factores de "interleave" son de 1:1, lo que significa que ya no se utiliza el interleaving.


Volver a Artículos y FAQs

 

     
 

Volver arriba Volver arriba

© 1997-2008 Duiops (http://www.duiops.net)
Prohibida la reproducción parcial o total de los textos o las imágenes

Para comentarios, usa las direcciones e-mail de contacto.