| Artículo de Thomas Rapp http://thomas-rapp.homepage.t-online.de/4gb_faq.html Traducción Diezi7 (Victor Gutiérrez) FAQ sobre el problema de los 4GB4GB no es un número mágico. Sólo es el valor máximo almacenable mediante 32 bits. Es 2 elevado a 32, que resulta ser 4,294,967,296. Los fabricantes de discos duros lo suelen denominar 4.3 GB. Para ser más exactos, el número más elevado almacenable es 4,294,967,295. Como se pueden almacenar 4,294,967,296 números diferentes, y cero es uno de ellos, los números estarán entre 0 y 4,294,967,295. ¿ Y por qué hay un límite ? Los números (offsets, tamaños etc.) tienen que almacenarse de algún modo. Y guardar números significa buscar memoria para los mismos. Y en un tamaño fijo de memoria solamente se pueden almacenar un número limitado de números. A finales de los años 1980, cuando se diseñó Amiga OS, el Amiga era un ordenador muy moderno. fue uno de los primeros ordenadores equipados con un procesador capaz de funcionar con 32 bits. Sólo hasta hace unos pocos años, el tipo de datos más grande manejable por cualquier lenguaje de programación de serie era un número de 32 bit. De modo que emplear en 1987 un numero de 32 bit para el tamaño de disco y offsets era algo adelantado a su tiempo. ¿ Dónde está el límite de los 4GB ? Lo crea la interfaz del controlador de hardware. El controlador del bus IDE interno se denomina scsi.device (si, el controlador IDE se llama SCSI por razones históricas y de compatibilidad). Todos los controladores del ".device" se acceden mediante la misma interfaz. Dicho interfaz entiende comandos como por ejemplo "lea x bytes que comiencen con el byte y". X e y son números almacenados en 32 bits como dijimos antes. Por lo general los discos duros se dividen en bloques de 512 bytes cada uno. Así que para leer el bloque 1.000 de un disco duro, se solicita al controlador "leer 512 bytes desde el byte 512.000". Nada complicado. Ahora imaginemos un disco duro grande y que el programa necesita leer el bloque 8,388,608. El comando será "leer 512 bytes partiendo del byte 4,294,967,296". Pero ojo. Este se puede almacenar igualmente en 32 bits. Pero desgraciadamente el lenguaje de programación no comprueba esto. Sin un chequeo explícito en el programa, un desbordamiento como este no puede ser reconocido. Lo que sucedería es que los bits desbordados serían eliminados empleándose únicamente los inferiores a 32 bits. Para 4,294,967,296 el bit 33 sería 1 y el resto de bits cero. Por ello el comando enviado al controlador sería "leer 512 bytes comenzando en el byte 0". Y aquí vemos el problema: el bloque 0 se ha utilizado dos veces. Si guardamos datos en un fichero que debiera almacenarse en el bloque 8,388,608, el bloque 0 sería sobreescrito. El Bloque 0 suele guardar la tabla de partición, de modo que se perderían todos los datos del disco duro y el ordenador ya no arrancaría. Sería como tener un disco duro vacío. ¿ Necesito un nuevo controlador de Disco Duro entonces ? No. El problema no está en el hardware. El hardware es capaz de manejar discos de cualquier tamaño. El límite de los 4GB está en el software y se puede corregir mediante software. ¿ Entonces instalando un nuevo scsi.device es suficiente ? No del todo. Como vimos antes las aplicaciones envían los comandos al controlador. Se puede cambiar el controlador para que acepte nuevos comandos, pero es necesario modificar también las aplicaciones para que sean de utilidad. ¿ Hay que reemplazar todas las aplicaciones ? No. Generalmente un programa no solicita al controlador directamente la lectura de bloques. Hay un par de capas software por medio. Los programas suelen realizar peticiones de lectura de ficheros a dos.library. Entonces la librería solicita al sistema de ficheros y este solicita al controlador la lectura de los bloques, De modo que la solución más recurrente consiste en reemplazar el sistema de ficheros así como el controlador del hardware, y así la mayoría de programas pueden hacer uso de discos duros más grandes de forma automática. Pero hay muchas aplicaciones que acceden directamente al scsi.device. Tales como los programas de defragmentación y recuperación. Estos deben ser modificados individualmente, y no pueden funcionar con un nuevo controlador. No me preocupa el tema del límite de los 4GB, divido mi disco duro en particiones más pequeñas, y todo funciona. CUIDADO !!! Craso error. El límite de los 4GB se aplica a todo el disco duro, no a las particiones. Scsi.device es una parte del problema. Y scsi.device no entiende de particiones. Contabiliza todo el disco duro como una gran corriente de bytes. Sólo conoce que hay por ejemplo un disco duro en la unidad 0 y un CD-ROM en la unidad 1, pero siempre se ven enteramente. Es dos.library quien se encarga de hacer las particiones. Dos.library monta una partición como : "HD0 comienza en el cilindro 2 y ocupa 1.000 cilindros, un cilindro cuenta con 1008 bloques y un bloque presenta 512 bytes". El sistema de ficheros recibe esta información y luego calcula los offsets. Si el sistema de fichero quiere leer el primer bloque del segundo cilindro de HD0, tendrá que leer el bloque 3.024 del disco duro (1,008 * 3) y el comando enviado a scsi.device será "por favor lea 512 bytes al comienzo del byte 1,548,288". De este modo, si una partición supera el límite de los 4GB y el sistema de ficheros calcula el offset de byte como números de 32 bits, empleará en su lugar partes del área anterior al límite de los 4GB, destruyendo datos importantes en otras particiones o incluso de la misma tabla de particiones. ¿ Cómo sustituyo scsi.device ? Bien, no se puede. Scsi.device es parte del Kickstart ROM y no es posible cambiarlo sin crear una nueva versión de ROM. Pero sí se puede parchear mediante software. Pero hay un gran handicap para este parche: cuando encienda su ordenador y la RAM se encuentre totalmente vacía, sólo existirá la versión ROM del scsi.device. Por ello accederá a la partición de arranque desde la que carga el sistema y se cargan los parches mediante la versión original de scsi.device. Quiere decir esto que la partición de arranque debe situarse dentro de los primeros 4GB's del Disco Duro. ¿ Qué solución existe ? ¿ Que haría un parche para scsi.device ? No hay una solución real para esto. Puesto que el parche no se puede aplicar sobre la ROM, se hace en RAM. Y cada que vez que apaque el ordenador se volatilizará. Debe cargarse durante el proceso de arranque. Eso implica dos necesidades: 1. La partición de arranque debe estar en el área accesible por el scsi.device original. Porque al encender el ordenador, sólo está activa la versión ROM de scsi.device, por eso la partición debe encontrarse al alcance de este scsi.device limitado. 2. Porque un programa en ejecución no es reemplazable al vuelo, se debe resetear el ordenador para que el parche sea aplicado. De lo contrario la nueva versión de scsi.device no estará activa. ¿ Entonces no puedo particionar un disco duro grande en una sola pieza ? Exacto. Pero no es un gran problema porque el Amiga siempre ha tenido más de una partición. Todo Sistema Amiga preinstalado contaba con una partición menor de sistema que contenía Workbench, fuentes, librerías etc. y una partición Work mayor para guardar los programas, datos, y demás. Por cuestiones de seguridad y backup incluso recomendaría tener más de una partición de arranque y más de una para trabajo o datos. ¿ No hay otra solución para utilizar discos duros grandes sin ese reset tedioso que ralentiza todo ? Hay una solución válida sin el parche para scsi.device, pero no es genérica. Sólamente permite cambiar el límite de 4 a 8GB. Mediante HD_SCSICMD, se pueden enviar comandos SCSI al controlador directamente. Se puede denominar Direct-SCSI también. Así se amplía el límite de 4GB a 2TB. Por desgracia no funciona así. En cuanto al hardware, scsi.device sigue funcionando mediante el esquema de direccionamiento CHS (Cilindro/Cabeza/Sector) para leer la capacidad. Y el límite para esto es de 16383 cilindros, 16 cabezas y 63 sectores lo cual resulta ser 16383 * 16 * 63 * 512 = 8,455,200,768 bytes o 7.87 GB. Me basta con 8 GB, ¿ Cómo lo hago ? Puede utilizar uno de estos sistemas de ficheros:
¿ Qué significa TD64 ? Estábamos hablando de comandos anteriormente. Los comandos "normales" y HD_SCSICMD por ejemplo. Los comandos "normales" son CMS READ y CMD WRITE. Ambos están presentes en todo controlador de ".device" y tiene un límite de 4GB. HD_SCSICMD es un comando diferente que sólo algunos controladores SCSI o IDE pueden entender. Y requiere de mayores esfuerzos de programación para hacer uso de él. TD64 se creó para superar el límite de los 4GB. Incluye nuevos comandos como TD_READ64 y TD_WRITE64. Emplean números de 64bits como tope y por tanto cuentan con un límite muy superior a los 4GB. Poco después de TD64, otro equipo de programadores creó un juego de comandos con idéntico propósito. Lo llamaron NSD y contiene los comandos NSCMD_TD_READ64 y NSCMD_TD_WRITE64. Funcionan exactamente como los comandos TD64 pero no son compatibles. Hay tres nuevos juegos de comandos que hacen lo mismo. ¿ Cúal debería utilizar ? No importa cual utilice. Debe buscar la combinación de controlador de .device y sistema de ficheros que soporten ambos el mismo juego de comandos. Con OS 3.5 NSD fue declarado el "estándar". Pero no lo soportan todos los desarrolladores de controladores de disco duro. ¿ NSD ? Bien. Puedo solventar mis problemas con NSDPatch. No, no es así. NSDPatch es de poca ayuda para el problema de los 4GB. Si, permite que muchos controladores de .device entiendan comandos NSD. Pero no reemplaza los controladores. El acceso al hardware sigue inalterado. Y como vimos antes, el límite absoluto de scsi.device es de 7,8 GB. Y este límite sólo es superable reemplazando el controlador, no mediante un parcheo. Así que para emplear un disco duro de 7,8GB, es mejor emplear uno de los sistemas de ficheros antes mentados en lugar de NSDPatch puesto que este sigue necesitando que la partición de arranque se sitúe dentro de los primeros 4GB. Bueno muy bien, ¿ de dónde puedo descargar el software necesario ? Nunca hay solución que sea sencilla y barata al mismo tiempo. Hay soluciones sencillas que puede usted comprar, y soluciones gratuitas complejas de instalar. Si tiene un Amiga que cumple todos los requisitos, lo más sencillo es adquirir AmigaOS 3.5 o 3.9. Ambos sistemas operativos incluyen todo lo que usted necesita. Para los dos, debería crear primero un disco de arranque de emergencia, arrancar desde el mismo y sólo entonces particionar su disco duro. Es la primera opción del menú de instalación en OS3.9, y la última en 3.5. Pero en ambos casos es lo primero que se debería hacer. No olvide situar la partición de arranque dentro de los primeros 4GB del disco duro. El resto de particiones puede organizarlas como mejor le convenga. No deseo actualizar el sistema operativo. ¿ Qué hago en ese caso ? Si se plantea seguir con OS 3.1, una solución es IDE-fix'97 (ahora llamado IDE-max'97; demo,full version). Para que IDEfix funcione, una vez instalado, edite el fichero s:startup-sequence y reemplace C:IDEfix por C:LoadIDE RESET. Debe también instalar un sistema de ficheros que soporte discos duros grandes. IDEfix soporta los tres juegos de comandos (HD_SCSICMD, TD64 and NSD), así que no hay restricción alguna sobre el sistema de ficheros a emplear. Recuerde que la partición de arranque debe estar en los primeros 4GB del disco duro. De acuerdo, pero ¿ qué sistemas de ficheros soportan discos duros de gran capacidad ? Los siguientes:
¿ Cúal es la solución económica ? Las actualizaciones incorporadas por OS 3.5 y OS 3.9 podían ser descargadas con anterioridad a su publicación de la página de Commodore Amiga Alemania. DJBase ha guardado los ficheros antes de que cerrase la página y es posible descargarlos desde este sitio: página de descarga Necesitará FastFileSystem versión 43.20 y scsi.device versión 43.24. Estos ficheros son las versiones beta originales que contienen comprobantes de fecha ya expirados. Por ello al instalarse emiten gran cantidad de advertencias antes de que su Amiga arranque. Hay en Aminet parches para eliminar tales mensajes molestos para scsi.device y para FastFileSystem. El parche para FFS es para una versión antigua. En la versión 43.20 el offset ha cambiado de $002A2C a $002A34. Por último, el programa LoadV43Module proporcionado con la actualización de scsi.device sólo funciona con Kickstart 3.1. Si quiere utilizarlo con versiones de kickstart anteriores, debería utilizar en su lugar el LoadModule de Thor: Enlace a Aminet. Pasos para la instalación:
¿ Es válido el mismo procedimiento si tengo una controladora de disco duro de terceras partes ? No. Scsi,device es el controlador para el IDE interno o el bus SCSI de los modelos Amiga de Commodore sólamente. Si cuenta con un controladora de terceras partes, cuenta con un driver diferente. Poder emplear discos duros grandes con estas controladoras depende del driver. Algunos soportan discos duros grandes mediante HD_SCSICMD o TD64. Otros quizá necesiten actualizar su firmware. Otras controladoras simplemente no soportan discos duros grandes. Si su controlador soporta HD_SCSICMD o TD64 y el sistema de ficheros también, puede crear particiones a su antojo, incluso de gran tamaño. Si su controlador soporta HD_SCSICMD o TD64, puede emplear NSD aplicando NSDPatch. pero en este caso la partición de arranque debe estar dentro de los primeros 4GB del disco duro. Instalé todo pero no estoy seguro de si todo funciona correctamente Descargue Check4GB de Aminet y ejecútelo. Le dirá si todo está bien. Enlace a Aminet Instalé el nuevo scsi.device pero HDToolbox sigue sin permitirme utilizar más de 7,8 GB Utilice el fichero FixHDDSize de Aminet antes de ejecutar HDToolbox. Enlace a Aminet Bueno, ahora el diagrama de HDToolbox es mayor, pero los números siguen indicando de 0 a 4095 MB y no más. Es el mismo problema de los 32 bits que indicamos al inicio. Si incrementa lentamente el tamaño de la partición, verá que salta de 4095 a 0 en cuanto sobrepasa el límite de los 4 GB. Es simplemente un problema de apariencia de HDToolbox. Intermante funciona correctamente. Las particiones parecen correctas pero me surgen extraños problemas con Workbench y herramientas de directorio que sólo muestran cantidades negativas de almacenamiento libre. Algunos programas no puedo instalarlos porque indican que no hay espacio suficiente El mismo problema de nuevo. Tratar de calcular la cantidad de almacenamiento en bytes con números de 32 bit de ancho desborda fácilmente tratándose de discos duros de gran capacidad. Números con signo desbordan a los 2GB (todo entre 2 y 4GB es tratado con signo negativo), y los números sin signo desbordan a los 4GB. No es fácil de solucionar. Para ello sería necesario corregir todos los programas con este problema. Sólo se puede tratar de evitar. Para ello puede crear particiones inferiores a 2GB. Tendrá muchas particiones pero ningún problema con las aplicaciones. Otra solución es rellenar la partición con ficheros dummy (vacíos) hasta que la suma indicada permita instalar programas. Una vez instalado el programa puede borrar los ficheros dummy. |
jueves, 27 de marzo de 2014
FAQ sobre el límite de los 4GB (Amiga)
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario