stringtranslate.com

Discusión:Formato de disco

/unformat deshaciendo el formato

Es relativamente falso que el formateo haga que pierdas todos tus datos, un simple /unformat [unidad] normalmente restaurará todos los archivos. — Comentario anterior sin firmar agregado por 67.51.19.86 (discusión • contribuciones ) 17:57, 15 de septiembre de 2005 (UTC) [ responder ]

Eso podría ser cierto en lo que la página llama "formateo de alto nivel", pero dudo que sea cierto en lo que respecta al "formateo de bajo nivel". En cualquier caso, la sección "Recuperación de datos de un disco formateado" dice "Al igual que en la eliminación de archivos por parte del sistema operativo, los datos de un disco no se borran por completo durante cada formateo de alto nivel". He cambiado el segundo párrafo para que diga "... algunos de estos datos podrían recuperarse con herramientas especiales" (no recomendaría reformatear un disco con un tipo de sistema de archivos arbitrario y esperar que todos los datos vuelvan fácilmente). Guy Harris ( discusión ) 23:13 31 may 2012 (UTC) [ responder ]
Sigue siendo incorrecto. Los datos siguen estando ahí. No puede haber ningún "podría ser cierto" en este documento. Es necesario seleccionar los hechos para este artículo, de lo contrario, el artículo no tiene sentido. Intente buscar EnCase para ver cómo se recuperan los datos. Mire la discusión de Peter Gutmann. Los datos no se pierden, solo se desindexan si solo está formateando y nada más.
Ahora corregido con citas (eran las más difíciles de encontrar :-). El formateo destructivo de bajo nivel es cosa del pasado, como las FDD y los discos duros ST506. Tom94022 ( discusión ) 20:18, 22 de noviembre de 2012 (UTC) [ responder ]

Formato rápido y NTFS

== == "Nunca utilice el formato rápido al formatear una unidad NTFS. Existe la posibilidad de que la unidad se dañe. Quizás no sea una posibilidad muy grande, pero existe. Más vale prevenir que curar".

¿Existe alguna información o enlaces que respalden esta afirmación?

Lo voy a eliminar ahora. No se proporcionó ninguna referencia y, de todos modos, no pertenece a este artículo. El artículo no dice qué significa formato rápido ni NTFS. -- Ropez 08:33, 23 de abril de 2006 (UTC) [ responder ]

Ninguna utilidad de desformateo puede recuperar los datos de una partición que fue formateada con el parámetro /u. Esta no es la forma más segura de destruir los datos anteriores; en su lugar, utilice algo como DBAN para destruir los datos antiguos; sin embargo, ningún software de borrado de discos garantiza la destrucción del 100% de los datos almacenados. Sólo la destrucción física del propio disco duro junto con las partículas magnéticas garantizará una seguridad completa. "Ninguna utilidad de desformateo puede recuperar los datos, pero esta no es la forma más segura de destruir los datos anteriores". Esta frase es contradictoria tal como está. --Ricardo Dirani 14:30, 16 de mayo de 2006 (UTC) [ responder ]


Si bien no soy un experto en este campo, sé que es posible recuperar datos que se han sobrescrito una cierta cantidad de veces debido a los pequeños residuos de datos sobrescritos en el disco; ese es el alcance de mis conocimientos para este caso en particular. Por lo tanto, si bien es posible que el software no pueda recuperar los datos, alguien con los conocimientos y la tecnología (y la unidad real) podría recuperarlos.

Ah, aquí hay un artículo relevante: MFSTM . Laogeodritt 14:42, 11 de junio de 2006 (UTC) [ responder ]

No me fiaría del artículo de MFSTM tal como está en este momento. Consulta los enlaces que publiqué en Talk:MFSTM , especialmente este [1], y también los argumentos que se analizan en el artículo sobre recuperación de datos . Mtford 19:59, 15 de agosto de 2006 (UTC) == ==[ responder ]

Sobre escritura

He eliminado esto:

", o mejor aún, se debe realizar un formateo de bajo nivel. Esto en realidad es incorrecto.



Los datos aún se pueden recuperar por medios físicos (consultando a especialistas en recuperación de datos ); para evitarlo, se debe borrar el disco de forma segura , aunque ni siquiera esto es una garantía perfecta. Solo la destrucción física del disco duro junto con las placas magnéticas garantizará que los datos hayan desaparecido realmente, pero si solo lo rompe en pedazos, los datos aún pueden recuperarse si se utiliza el método adecuado.

Cualquiera que desee que se vuelva a incluir esto o algo similar, debe vincularse a una empresa, software o hardware que pueda recuperar datos que se han sobrescrito. Véase también Gutmann_method , donde el propio Gutmann desmiente el mito de que los datos sobrescritos están disponibles. DanBeale 11:06, 29 de marzo de 2007 (UTC) [ responder ]

Gracias por añadir esta nota y el enlace a la declaración del propio Gutmann en el epílogo, donde escribió que muchos han malentendido por completo lo que había escrito; ¡y en una época en la que los discos duros no se parecían en nada a lo que son hoy! Daniel Feenberg, cuyo artículo figura como crítica al llamado "Método Gutmann" allí, me envió un correo electrónico y me pidió que revisara su artículo. Aparte de una de las últimas frases que parecía demasiado personal sobre el propio Gutmann, en general estoy de acuerdo con su evaluación del tema. Incluso si las agencias gubernamentales tuvieran algunos de los equipos que los ciudadanos paranoicos creen que tienen, simplemente no pueden darse el lujo de perder todo el tiempo que llevaría encontrar algunos fragmentos de datos completamente fuera de contexto. Por cierto, la razón por la que Feenberg se puso en contacto conmigo fue que había encontrado mi propia página web aquí: http://thestarman.pcministry.com/asm/mbr/WIPE.html "Cómo borrar permanentemente los datos de un disco duro". Daniel B. Sedory 10:24 15 abril 2007 (UTC) [ responder ]
Ah, me olvidé de decir esto: una cosa que realmente me molesta son aquellos que usan la frase " formato de bajo nivel " cuando hablan de discos duros. Mucha gente ignorante sigue difundiendo la idea de que no sólo se debería hacer esto en los discos duros, sino que incluso es posible; lo cual definitivamente NO es para nadie que no tenga acceso a una fábrica de discos duros para cualquier disco duro moderno (de más de 12 años o más), así que estoy muy contento de ver que algo así se elimine de este artículo. Daniel B. Sedory 10:43, 15 de abril de 2007 (UTC) [ responder ]

Recuperación de datos de un disco formateado

En el último párrafo, el artículo afirma que el comando FORMAT de DOS sobrescribe por completo cada sector cuando se ejecuta en un disquete escribiendo bytes F6h en cada sector. Cada sector de un disquete contiene 512 bytes, que son 200 en hexadecimal. ¿De dónde obtuvo F6? F6 = 246 en decimal o 11110110 en binario. 246 es un número inusual, ya que la mayoría de los números en informática son potencias de 2.

Además, la antigua versión DOS del formato solo escribía ceros en los sectores si se usaba la opción /u (incondicional); de lo contrario, los datos se podían recuperar con el comando unformat.

Los archivos de ayuda de Windows Vista indican que la utilidad de formato elimina todos los datos del disco, a menos que se seleccione la opción de formato rápido, en cuyo caso crea una nueva tabla de archivos sin sobrescribir el disco. El programa de formato de línea de comandos también tiene una opción /p: que escribe un 0 en cada sector direccionable de la unidad varias veces (usted proporciona el número de pasadas después de /p:). Sin embargo, los sectores defectuosos siguen siendo un problema, ya que no hay forma de determinar si la unidad pudo sobrescribirlos correctamente. Si no es así, los sectores defectuosos podrían contener una imagen de datos previamente almacenados allí. David J. Dreier 18 de octubre de 2007.

F6 es el valor que se escribe en cada byte del disco. Así: F6F6F6F6F6F6... Reformularé la frase del artículo.

--Xerces8 ( discusión ) 17:25 22 nov 2007 (UTC) [ responder ]

David, aunque la edición reciente de Xerces8, en la que agregó "valor de byte" antes de "F6h", es útil, la idea clave habría sido " llenar cada sector" con bytes 'F6h'; no solo escribirlo una vez.
¿Sabes qué versión de DOS escribió bytes cero durante un FORMAT (y no bytes 'F6')? ¿Has realizado alguna prueba para verificarlo? Eso es algo que desconozco, pero podría probar en el futuro ya que tengo acceso a varias versiones de DOS de un amigo coleccionista. ¿Hay algo en la red o en un manual que especifique lo que escriben ciertas versiones de DOS? He realizado muchas pruebas con el comando FORMAT, pero no recuerdo haber visto nada excepto bytes 'F6' durante un FORMAT.
También me gustaría señalar que hasta la función de borrado de datos real de VISTA, aparentemente reciente (aún no la he examinado por mí mismo), sólo el formateo de disquetes (y posiblemente particiones bastante pequeñas en discos duros) borraba realmente todos los datos (que era posible sobrescribir) de un medio. Realizar un FORMATEO en particiones de disco duro grandes (de FAT32 y NTFS, por ejemplo), deja una gran cantidad de datos atrás. Como dice el artículo, sólo lo que se SOBRESCRIBE es lo que realmente se elimina. Daniel B. Sedory ( discusión ) 02:23, 27 de noviembre de 2007 (UTC) [ responder ]
He añadido información sobre esto al artículo, junto con una captura de pantalla (que hice yo mismo hace años para un antiguo servidor de listas de correo) que muestra explícitamente que incluso FORMAT /U no siempre sobrescribe. Tenga en cuenta que en mi caso, la partición tenía un tamaño de solo 8 MB y, además, estaba ejecutando MS-DOS 6.22a en ese momento, lo que significa que el tipo de partición habría sido FAT12 o FAT16 (no recuerdo cuál era, pero como FAT12 admite hasta 32 MB, podría haber sido cualquiera de los dos). Tenga en cuenta también que, si bien estaba usando NDOS 8.0 como reemplazo del shell COMMAND.COM en ese momento, NDOS 8.0 no tenía reemplazos integrados o externos para FORMAT.COM o UNFORMAT.COM; por lo que las versiones de FORMAT y UNFORMAT utilizadas en la captura de pantalla eran, de hecho, MS-DOS 6.22a. 71.160.20.130 (discusión) 09:40 6 mar 2010 (UTC) [ responder ]
F6h es el valor que se utiliza normalmente para disquetes y discos duros en máquinas compatibles con IBM-PC, pero otros fabricantes han utilizado otros valores en el pasado. Por ejemplo, los disquetes CP/M de 8 pulgadas normalmente venían preformateados con un valor de relleno de formato de E5h; esto también se implementó en las herramientas de formato de Digital Research y, por lo tanto, este valor también llegó a Atari ST y algunos medios formateados FAT de Amstrad/Schneider. Amstrad también utilizó un valor de relleno de formato de F4h. Hoy en día, los discos duros a veces se inicializan con un valor de 00h, mientras que FFh se utiliza normalmente en discos flash.
El BIOS (y el DOS) recuperan el valor que se debe utilizar de la DPT (INT 1Eh), una estructura de datos que normalmente configura el BIOS en el momento del arranque, pero que las herramientas de disco pueden tomar y modificar más adelante. Algunas herramientas del DOS permiten anular este valor.
Aunque me gustaría aprender sobre otros valores utilizados históricamente (si hay más), la pregunta más interesante es: ¿por qué F6h específicamente (o cualquier otra cosa)? Hasta donde recuerdo, esto era originalmente solo un artefacto del proceso de formateo de bajo nivel o/y (si era variable) "un patrón de bits que era particularmente bueno para distinguir en los primeros controladores". No me extiendo aquí porque (sin buscar esto) no recuerdo los detalles de los controladores FM/MFM después de tanto tiempo, pero tal vez todavía sea un indicador lo suficientemente bueno para que alguien más encuentre y describa la razón técnica exacta de este valor. -- Matthiaspaul ( discusión ) 07:15, 2 de agosto de 2012 (UTC) [ responder ]

Equipo de expertos de Best Buy

Estoy un poco confundido con este formato de bajo nivel. Según este artículo, el formato de bajo nivel borra todos los datos y estos datos son irrecuperables. Pero tuve una discusión con los "Geeks" de "Best Buy", quienes me dijeron que su software de recuperación de datos puede recuperar hasta 600 GB de datos (incluidos los sobrescritos) de un disco duro de 120 GB incluso si se realiza un formato de bajo nivel. Entonces, ¿en qué afirmación debo creer?

Ay, vaya. Te sugiero que tomes con pinzas muchas de las cosas que te dicen los "geeks" de Best Buy. Nada de esto se puede hacer solo con software si los datos se sobrescriben realmente, nunca. Punto. Antes era posible, con los discos duros de baja densidad más antiguos, desmontarlos hasta dejarlos en su estado puro, montar sus platos en un equipo especial de microscopio alojado en laboratorios de sala limpia y recuperar parcialmente los datos sobrescritos. Con los discos duros modernos, la recuperación de los datos sobrescritos simplemente no es posible, a menos que la CIA o la DIA sepan algo, en cuyo caso no hablan y, por lo tanto, solo la CIA/DIA pueden hacerlo. Lee esto. Además, no olvides firmar tus añadidos (con cuatro tildes) en el futuro. :) 71.160.20.130 (discusión) 10:16, 6 de marzo de 2010 (UTC) [ responder ]

¿Por qué el formato no borra todos los datos?

¿Cómo puede ser que un formato ("no rápido") no borre todos los datos? ¿Cómo se hace exactamente la prueba para detectar sectores defectuosos? Si se hace escribiendo datos en cada sector y luego probando si lo que se ha escrito es lo mismo que se ha leído, ¿cómo puede ser que no se sobrescriba ningún dato y se conserve en el disco? ¿Alguien puede resolver este misterio? 195.135.137.107 (discusión) 15:16 27 nov 2007 (UTC) [ responder ]


En el formato "largo" de Windows, la comprobación de los sectores defectuosos se realiza leyendo cada sector, no escribiendo en él. Las unidades modernas incluyen corrección de errores y reasignación de sectores en el controlador de la unidad. Si intenta leer un sector que está fallando, la unidad intentará recrear los datos faltantes (http://en.wikipedia.org/wiki//Reed%E2%80%93Solomon_error_correction) y escribirlos en un sector de repuesto. Luego actualizará el mapa de la unidad para que el sector defectuoso se marque como defectuoso y haya un puntero al nuevo sector "de repuesto". Por lo tanto, simplemente leer cada sector es suficiente para que la unidad se "repare sola".

También es probable que esta sea una razón por la que las agencias gubernamentales aún consideran que las unidades con "borrado de cero" son confidenciales. Si aparecen sectores defectuosos durante la vida útil de la unidad, se asignan automáticamente y nunca se vuelven a utilizar. No se sobrescribirán si la unidad está llena de ceros. Los datos de esos sectores aún se pueden recuperar si se pone el controlador de la unidad en un modo de diagnóstico especial y se le indica que lea directamente los sectores defectuosos asignados.

118.90.57.194 (discusión) 21:23 14 sep 2011 (UTC) [ responder ]

No puedo entender un párrafo

Hola, no tengo el inglés como lengua materna. La última frase: Desde la perspectiva de evitar la recuperación de datos sensibles a través de herramientas de recuperación, los datos deben sobrescribirse completamente (cada sector) con datos aleatorios antes del formato, o el programa de formato debe realizar esta sobrescritura; como lo hizo el comando FORMAT de DOS con los disquetes, llenando cada sector de datos con el valor de byte F6 en hexadecimal.

¿Significa esto que el FORMATO DOS puede impedir que se recuperen los datos? Si quiero evitar que se recuperen los datos del formato, ¿qué debo hacer? ¿Formatarlos de NTFS a FAT32 y luego volver a NTFS? ¿Funciona? —Comentario anterior sin firmar añadido por 222.71.122.88 (discusión) 04:50, 3 de febrero de 2009 (UTC) [ responder ]

"Reformatear"

El término "Reformat" significaría lógicamente "formatear de nuevo", como se forma con el sufijo "Re-" con la palabra "format". Sin embargo, el término "Reformat" no está aceptado oficialmente por el Diccionario Merriam Webster ni por el Diccionario Ask.com. Esto se debe posiblemente a que el término no es diferente del término "Format"; ambas definiciones son la misma. —Comentario anterior sin firmar añadido por 99.41.247.244 (discusión) 21:56, 15 de agosto de 2009 (UTC) [ responder ]

Declaración general calificada, enlace añadido, historial corregido

He modificado la sección de historial para

Tres niveles de formato

Esta sección tiene como objetivo analizar una disputa en curso sobre el número de niveles de formato y tratar de resolver una guerra de edición. El artículo original solo analizaba el formato de alto y bajo nivel. En realidad, hay tres:

  1. Formateo de bajo nivel, que normalmente se realiza en la fábrica y que implica cosas como escribir marcas de tiempo.
  2. Preparación del disco para que lo utilice el sistema operativo. En el caso de una PC, esto suele implicar la creación de particiones . En el caso de los mainframes IBM, esto suele implicar la creación de una etiqueta de volumen y una tabla de contenidos de volumen ( VTOC ).
  3. Preparación de una unidad, partición o unidad lógica para su uso por parte de un sistema de archivos. En el caso de una PC, esto se suele realizar con la utilidad de formato . En el caso de los mainframes IBM, se puede realizar de diversas formas, según el método de acceso.

Puedo proporcionar documentación para cada uno de los tipos de formato mencionados anteriormente, y el tipo intermedio se remonta a la década de 1960. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 23:24, 21 de diciembre de 2010 (UTC) [ responder ]

Hola. He aceptado una solicitud de WP:3O para esta página. Observo que esta solicitud no se ha anunciado aquí y no puedo encontrar ninguna disputa en curso ni, de hecho, ningún segundo editor involucrado. Todas estas circunstancias sugieren que una solicitud de 3O puede haber sido inapropiada y que una "Solicitud de comentarios" puede funcionar mejor. 3O es solo para resolver problemas entre 2 editores en disputa. Si un segundo editor se comunicara conmigo en mi página de discusión para confirmar el punto muerto y que solo hay 2 editores involucrados, estaría encantado de ayudar. Nota: la solicitud se ha eliminado de la página de 3O y sigo dispuesto a ayudar con la resolución. Gracias. Redheylin ( discusión ) 00:45, 22 de diciembre de 2010 (UTC) [ responder ]
Lo siento. El otro editor inició el diálogo en User talk:Chatul#Yr Disk Formatting Edit en lugar de en Talk:Disk formatting, y no mencioné este hecho en mi solicitud. Le pedí a Tom94022 ( talk ) que se comunicara con usted y confirmara que se trata de una disputa entre dos partes que se encuentra en un punto muerto. Mientras tanto, ¿hay algún detalle o cita que deba agregar a esta discusión? Gracias. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( talk ) 12:53, 22 de diciembre de 2010 (UTC) [ responder ]
  1. ^ Google: unidad de disco con "formateo de bajo nivel" = 78.500 resultados
  2. ^ Google: unidad de disco con "formateo de alto nivel" = 36.900 resultados
  3. ^ Busque en Google "formato de nivel intermedio" en la unidad de disco = 656 resultados, en su mayoría irrelevantes, pero tenga en cuenta que Veritas parece usar el término sin definir exactamente a qué corresponde.

Tom94022 ( discusión ) 22:18 22 dic 2010 (UTC) [ responder ]

Como dije en respuesta a sus comentarios en mi página de discusión, la disputa es sobre la cantidad de niveles, no sobre la nomenclatura de cada nivel. El artículo habla sobre el formateo de bajo nivel como algo que se hace en la fábrica, y las funciones a las que me referí como intermedias están claramente en un nivel superior. Ya dije que no tengo objeción si desea utilizar un término diferente para describir el nivel intermedio, y el uso de un término puramente descriptivo no constituye OR.
El texto anterior del artículo no describía a fdisk y otros como de bajo nivel. Véase, por ejemplo, Formato de disco#Transición desde LLF
Después de un formateo de nivel bajo e intermedio, el medio puede ser utilizado por un sistema operativo. En z/OS, algunos métodos de acceso no requieren un formateo de alto nivel de las pistas antes de escribir en ellas. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 23:12, 22 de diciembre de 2010 (UTC) [ responder ]


Vale. En primer lugar, Tom tiene razón al decir que quienes presentan ideas tienen la obligación de citarlas. Sin embargo, no sería adecuado que yo me retractara de lo que él pide. Además, observo que la calidad de las citas en este artículo es, en general, deficiente. Los resultados de Google, los blogs, etc. no deberían ser necesarios en un área que está repleta de documentación de alta calidad. Chatul tiene razón en que el proceso de formateo en HD implica varias etapas y que la clasificación de HL y LL puede ser insuficiente, y que la terminología utilizada puede no ser absolutamente coherente. Aun así, las afirmaciones introducidas SIEMPRE deben tener como fuente obras autorizadas.
Al consultar un viejo libro de texto ("Operating System Concepts" de Peterson y Silberschatz) descubro que NO se menciona el término "formato". Incluso si leo "Tricks of the MS-DOS Masters" de The Waite Group, el comando "FORMAT" se define como "inicialización de disco". Creo que es justo concluir que el término "formato" es, para empezar, un término de Microsoft, pero esto no se aclara aquí. Me gustaría sugerir que ambos cooperen en la creación de este artículo desde el nivel más básico (¡formateo de bajo nivel!) utilizando únicamente material de referencia. Creo que, si lo hacen, habrá un mejor artículo y menos problemas. Los problemas se deben a la aceptación de la terminología y los conceptos sin rastrear su origen y su historia, y el resultado es un artículo deficiente. Creo que si trabajan juntos a partir de los mejores textos que puedan, descubrirán que el problema simplemente ha desaparecido por el camino. Los artículos OR invitan a más OR. ¿Algún comentario? Redheylin ( discusión ) 00:53 23 dic 2010 (UTC) [ responder ]
Para que lo sepas, el término formato y la utilidad FDISK creo que se remontan al menos a CPM. El término más común puede ser "inicializar".
Para que conste, el Apéndice B del Manual de generación del sistema DEC RT-11 (julio de 1976) se titula "Formateo del disco RK05". El procedimiento parece un "formato de bajo nivel" no muy diferente del proceso BIOS utilizado por las PC, pero produce un disco "ahora formateado y listo para usar". Cito esto para mostrar que el término es anterior a Microsoft y este proceso de bajo nivel aparentemente realiza un formateo de bajo nivel y un formateo de alto nivel para usar términos del arte. Esto hace que tanto el texto de Chatul como el mío sean inexactos. Tom94022 ( discusión ) 02:16, 23 de diciembre de 2010 (UTC) [ responder ]
Como a Chatul no le importa la terminología, he cambiado el título de la sección y he cambiado "formateo de nivel intermedio" por "Particionado", lo que debería obviar ambas objeciones. Todavía hay problemas con la sección de reinicialización del disco , que es donde tratamos la idea de que el particionamiento es (mi opinión) o no es (la opinión de Chatul) parte del formateo de bajo nivel. Tom94022 ( discusión ) 01:35, 23 de diciembre de 2010 (UTC) [ responder ]
Eso estaría bien para las PC, pero viola el NPOV , ya que el nivel intermedio de formateo en mainframes no implica particionamiento. ¿Puedes pensar en un término correcto y razonablemente corto en su lugar? Gracias. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 14:38, 23 de diciembre de 2010 (UTC) [ responder ]
También se aplica a UNIX. Tengo que investigar y pensar un poco más sobre el tema, pero hasta cierto punto la partición en el contexto de una sola partición puede ser una descripción precisa de lo que usted llama "formateo de nivel intermedio" para mainframes IBM; es decir, registrar en los bloques información que permite al SO reconocer uno o más discos lógicos. Por cierto, ¿tiene alguna evidencia de que el resto de BUNCH lo haya hecho de esta manera? Por eso prefiero dos pasos, el nivel bajo es todo lo que hace que el disco esté disponible para el SO y el nivel alto es todo lo que hace que el disco sea utilizable por un sistema de archivos. La forma en que se hace esto varía con el tiempo según la tecnología y el SO, pero fundamentalmente me parece que es un proceso de dos pasos. Lamentablemente, no parece haber ningún material publicado que generalice el tema del "formateo", por lo que todo lo que hacemos es más WP:OR que WP:NPOV, ninguno de los cuales debería estar en un artículo. Tal vez la única salida sea no generalizar y reescribir el artículo en dos o tres secciones, una sobre PC y UNIX, una segunda sobre mainframes IBM y posiblemente una tercera sobre Apple (sospecho que es algo parecido a PC/UNIX). Tom94022 ( discusión ) 19:43 23 dic 2010 (UTC) [ responder ]
Ambos parecen no haber entendido el asunto. No tiene sentido hablarme AQUÍ de las cosas, en particular cuando seguís hablando como si fuerais los expertos del mundo. No es un combate de boxeo, no hay premios. ¿Es necesario que os digan a todos lo inteligentes, expertos y RAZÓN que sois? Escribid un blog: Wikipedia sirve para recopilar las declaraciones de expertos publicados. Ambos estáis actuando de forma disruptiva. Os pido a ambos que dejéis de hacer guerras de ediciones y trabajéis el artículo entero, sustituyendo las declaraciones por las de fuentes verificables y autorizadas. Redheylin ( discusión ) 23:51 23 dic 2010 (UTC) [ responder ]
El artículo ya habla de la partición, que se encuentra entre lo que el artículo llama nivel bajo y lo que el artículo llama nivel alto. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 00:37, 24 de diciembre de 2010 (UTC) [ responder ]
En realidad, tú, Redheylin , no has entendido nada y realmente estás actuando fuera de tu supuesto papel de arbitrar un punto muerto. En primer lugar, mis comentarios están dirigidos a Chatul y a cualquier otro editor que pueda contribuir a las discusiones; tomo los de Chatul con el mismo espíritu. Tu sarcasmo y tus insultos ad hominum no sirven para nada y son inapropiados para una discusión en Wikipedia. En segundo lugar, no hay nada disruptivo en esta discusión y, de hecho, parece que se está llegando a un acuerdo. En tercer lugar, no se trata de una guerra de ediciones, ya que la mayor parte es una discusión bastante experta de los hechos relevantes en una página de Discusión ; casi por definición, no es una guerra de ediciones. En conclusión, en mi opinión, tu conducta es inapropiada y, si no tienes nada útil que decir, entonces deberías considerar mantenerte en silencio. Tom94022 ( discusión ) 02:20, 24 de diciembre de 2010 (UTC) [ responder ]
¿Qué tal si llamamos al nivel intermedio Preparación para el uso del SO ? No veo cómo usar un término descriptivo es O.
El problema con la frase descriptiva Preparación para el uso del SO es que me parece que significa todo lo que se hace para que el disco esté disponible para el SO, lo que incluiría tanto la colocación de los bloques apropiados en el disco como la escritura en ellos de la información que hace que el disco sea accesible para el SO, es decir, en los términos actuales del artículo tanto "formateo de bajo nivel" como "particionado". Por cierto, incluso los sistemas IBM actuales pueden requerir un formateo de bajo nivel si, por ejemplo, uno quisiera instalar un HDD formateado en un tamaño de bloque en un subsistema que requiere un tamaño de bloque diferente, aunque admito que este es un evento inusual. Voy a hacer algunos cambios menores a la sección mientras lo solucionamos. Tom94022 ( discusión ) 02:20, 24 de diciembre de 2010 (UTC) [ responder ]
Utilicé términos como mainframes de IBM porque no sabía cómo lo manejaban los Siete Enanitos o los demás proveedores. Sin duda, agradecería que alguien de, por ejemplo, XDS, pudiera añadir esa información.
El artículo original analizaba el formateo de fábrica, que se encuentra en un nivel diferente del particionamiento, ICKDSF et al.
Me gusta la idea de agregar secciones para varias plataformas, si podemos encontrar editores con experiencia en, por ejemplo, CDC.
Hay material publicado que describe particionamientos específicos y otros niveles intermedios de formateo; puedo proporcionar enlaces en línea para los mundos de PC y mainframe de IBM. ¿Sería apropiado proporcionar solo una referencia reciente para cada uno, o también referencias más antiguas? Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 00:37, 24 de diciembre de 2010 (UTC) [ responder ]

La reversión sin discusión es una guerra de ediciones, al igual que lo es pedirle a otros que la reviertan, y la guerra de ediciones siempre es disruptiva. Y en este caso es inútil, porque es seguro que tu trabajo será sobrescrito por un editor que usa fuentes disponibles y notables y si alguien la revierte, probablemente será bloqueado al final. Muchas veces sucede que la persona que tiene más "razón" es también la más agresiva, y entonces esa persona es bloqueada, tenga razón o no. Chatul escribe: "Puedo proporcionar enlaces en línea para los mundos de PC y mainframe de IBM. ¿Sería apropiado proporcionar solo una referencia reciente para cada uno, o también referencias más antiguas?" Por el momento, Chatul, simplemente agrega la referencia que consideres más autorizada y permanente. Las buenas fuentes en línea, NO blogs o sitios de pasatiempos, serán muy valiosas. Luego debes aceptar fuentes contradictorias con buenas referencias junto con estas, pero puedes eliminar o revertir cualquier investigación original . Entonces no hay necesidad de buscar expertos en CDC y otras plataformas, solo encuentra las fuentes y agrégalas: es mejor que los "expertos" que confían en su propia experiencia. "Google Scholar" y "Google Books" están ahí para que los usemos. Copie autor - título - editorial - fecha - página y añada el enlace, y esto será defendido. La investigación original y el conocimiento editorial desaparecerán pronto y, como digo, usted o cualquier persona pueden ser bloqueados si se resiste. Nadie quiere eso. Redheylin ( discusión ) 06:06 25 dic 2010 (UTC) [ responder ]

Redheylin, ¿te diste cuenta de que estos temas se discuten en esta y otras páginas de discusión? Si lees WP:Edit warring verás que no estamos en una guerra de ediciones y que no estamos cerca de una situación WP:3RR . No estoy seguro a qué se refiere tu comentario sobre "sondeo", pero si te refieres a mi solicitud de que, como árbitro, vuelvas al original hasta que se alcance un consenso, eso no es en ningún sentido "sondeo". Así que, por favor, deja de predicar y de atacar ad hominem . Tom94022 ( discusión ) 18:15, 25 de diciembre de 2010 (UTC) [ responder ]

No he podido encontrar ninguna publicación que trate genéricamente el tema del formateo de discos, por lo que lo que sigue es WP:OR , pero me parece que un tratamiento tan genérico identificaría cuatro niveles de formateo de la siguiente manera:

  1. El primer nivel, opcional, es la colocación de la información de posicionamiento en el medio. Esto no se hace en los discos duros ni tampoco en los primeros discos duros, pero ahora se hace en todos los discos duros y siempre se ha hecho en los discos ópticos. La información de posición puede estar grabada como en los discos duros o incrustada de forma permanente como en los discos ópticos. Este es siempre un proceso de fábrica.
  2. Organización de las superficies del disco en bloques. Según el primer paso, la organización de los bloques puede estar limitada o incluso determinada por la naturaleza de la información de posición. En los primeros discos duros (es decir, cualquier unidad como una unidad CKD que no utilice servos de sector) y discos duros fijos no existían tales limitaciones. Los discos duros han evolucionado desde una limitación algo estricta a una limitación técnicamente nula (grabación de campo dividido sin encabezado), pero una fuerte limitación de facto debido al tamaño de bloque omnipresente de 512 bytes. Las unidades de discos ópticos siempre han estado severamente limitadas. A veces, este es un proceso de fábrica, pero puede ser un proceso de usuario.
  3. Escribir información en los bloques que sea suficiente para permitir que el sistema operativo reconozca el medio. Esto puede ser un proceso de fábrica, pero siempre existe una forma de hacerlo para el usuario.
  4. Escribir información en los bloques suficiente para permitir que el medio sea utilizado por al menos un sistema de archivos. Esto siempre es una capacidad del usuario y casi siempre es un proceso del usuario, pero en algunas situaciones de gran volumen puede ser un proceso de fábrica.

El problema que tenemos es que el artículo comenzó con una orientación sólida sobre discos duros y discos flexibles para PC que es incompleta e incluso inexacta cuando se la considera a la luz de otros sistemas operativos y otros medios. Chatul y yo hemos estado tratando de mejorar el artículo de manera incremental sin reescribirlo por completo, pero la realidad del tema es que la ausencia de una publicación genérica significa que o será malo o tendrá que haber algún aporte de un experto. Si alguien puede encontrar una publicación de este tipo, sería de gran ayuda. Tom94022 ( discusión ) 04:29, 26 de diciembre de 2010 (UTC) [ responder ]

"No he podido encontrar ninguna publicación que trate de forma genérica el tema del formateo de discos"; en ese caso, el tema de la página no tiene relevancia y debería borrarse. Redheylin ( discusión ) 08:25 26 dic 2010 (UTC) [ responder ]
La ausencia de un tratamiento genérico del tema no significa que el tema no sea notable; su notoriedad se establece por referencia a uno, por ejemplo. Tom94022 ( discusión ) 17:57 26 dic 2010 (UTC) [ responder ]
La ambigüedad del término “formato de bajo nivel” parece deberse tanto a la documentación inconsistente en los sitios web como a la creencia de muchos usuarios de que cualquier proceso por debajo de un “formato de alto nivel (sistema de archivos)” debería llamarse formato de bajo nivel. En lugar de corregir este concepto erróneo (indicando claramente que un proceso de este tipo no se puede realizar en unidades específicas), los fabricantes de unidades han descrito varios programas de restablecimiento como utilidades LLF en sus sitios web. Debido a que los usuarios generalmente no tienen forma de determinar la diferencia entre un LLF verdadero y un restablecimiento (simplemente observan los resultados de ejecutar un programa en un disco duro que se va a particionar y un “formato de alto nivel”), como el usuario está mal informado y tiene señales confusas, varios fabricantes de unidades han perpetuado este error. http://unix.org.in/2010/10/disk-formatting/ Redheylin ( discusión ) 11:18, 26 de diciembre de 2010 (UTC) [ responder ]
La cita anterior es de una sección del artículo que dice "Esta sección necesita citas adicionales para su verificación", por lo que difícilmente puede considerarse una fuente confiable. También es casi palabra por palabra la sección de reinicialización de disco de este artículo. La buena noticia es que el artículo de UNIX describe el formateo de discos de UNIX como un proceso de dos pasos. La mala noticia es que es un artículo de UNIX y se parece mucho a este artículo de Wikipedia (incluida la cita anterior), por lo que no queda claro quién copia a quién y nuevamente nos encontramos con la pregunta de si es una fuente confiable. Tom94022 ( discusión ) 18:07, 26 de diciembre de 2010 (UTC) [ responder ]

¿Qué es ICKDSF?

Comencé esto como un hilo separado de la cantidad de niveles de formato para que podamos discutir el enfoque del mainframe de IBM en una sección.

He descargado (gratis) y estoy revisando la versión 17 de la Guía del usuario y referencia de ICKDSF para ver cómo describe su proceso de poner un disco a disposición de un sistema. A primera vista, me parece que en los dispositivos CKD nativos realiza tanto un "formateo de bajo nivel" como la puesta a disposición del volumen (dispositivo) para el sistema. Lo explicaré con más detalle después de haber leído un poco más, pero si alguien tiene algún comentario, por favor agréguelo. Tom94022 ( discusión ) 05:48, 24 de diciembre de 2010 (UTC) [ responder ]

Para que conste

Parte 2 de la versión 17 de la Guía y referencia del usuario de ICKDSF "Uso de ICKDSF para instalar y mantener dispositivos CKD", Capítulo 18. Comando INSTALL: CKD, establece en parte que "el comando INSTALL es un procedimiento de instalación mejorado que incluye la escritura de la dirección de inicio y el registro 0 en cada pista de un volumen 3380, 3390 y 9345". En los términos de este artículo, el comando INSTALL realiza un "formato de bajo nivel" ya que crea las marcas de tiempo asociadas a HA y RO y, además, realiza una parte de "particionado" ya que escribe información en el campo RO y HA necesaria pero no suficiente para el acceso a MVS. El comando INIT (Capítulo 16) luego completa el proceso de "particionado" escribiendo "la etiqueta de volumen y VTOC en volúmenes para uso de sistemas operativos MVS o VSE" completando así el proceso de hacer que el medio de la unidad de disco esté disponible para el SO. Si bien esta utilidad no se ocupa de las unidades CKD anteriores al 3375, estoy seguro de que este es el proceso utilizado para todas las unidades CKD hasta el 2311.
La Parte 3 de la Versión 17 de la Guía y Referencia del Usuario de ICKDSF "Cómo usar ICKDSF para instalar y mantener dispositivos FBA" no parece abordar el cambio del tamaño del bloque físico (hasta donde puedo decir, requiere un bloque físico de 512 bytes) y no utiliza el comando INSTALL.

Personalmente, creo que el proceso CKD realizado por ICKDSF respalda mi opinión de que existe un proceso de "bajo nivel" que consta de dos pasos: bloqueo (el comando INSTALL) y reconocimiento de volumen (el comando INIT). El proceso FBA de ICKDSF es solo la parte de reconocimiento de volumen del proceso de "bajo nivel"; el bloqueo se realiza en la fábrica o mediante una utilidad SCSI o IDE.

También observo que esto aparentemente contradice la afirmación de que ICKDSF y otras utilidades similares no pueden recuperar la sincronización perdida. De hecho, en cualquier HDD de superficie servo dedicada, como en los FDD, la utilidad de partición o incluso de formateo podía manejar, y de hecho lo hacía, funciones de bajo nivel como las marcas de sincronización. Por eso se los llamaba sectores blandos. Tom94022 ( discusión ) 20:17, 25 de diciembre de 2010 (UTC) [ responder ]

Lamento no haberme comunicado contigo antes; Verizon cortó mi circuito local mientras atendía una llamada de servicio para mi vecino y se tomaron su tiempo para arreglarlo.
El comando INSTALL de ICKDSF no escribe marcas de sincronización; HA y R0 están en un nivel superior. De hecho, INSTALL se utiliza para discos que requieren formateo de fábrica, no para los discos más antiguos que se pueden inicializar por completo en el sitio. Tenga en cuenta la declaración "Tareas que puede realizar con ICKDSF". Guía del usuario y referencia de Device Support Facilities (ICKDSF) R17 . Nota: Las funciones de verificación de superficie realizadas por ICKDSF no son equivalentes a la verificación de superficie que se realiza en un volumen en la fábrica. Para obtener más información, consulte el Apéndice E. Verificación de superficie. {{cite web}}: Parámetro desconocido |separator=ignorado ( ayuda )
La versión más reciente de la documentación de ICKDSF parece ser IBM Device Support Facilities (ICKDSF) User's Guide and Reference R17 (PDF) . GC35-0033-36. {{cite book}}: Parámetro desconocido |separator=ignorado ( ayuda ) Versión HTML; eso debería ir en el artículo. Si . Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 19:45, 30 de diciembre de 2010 (UTC) [ responder ]
Bienvenidos nuevamente. Cuando un sistema IBM emite un comando WRITE HA o WRITE RO a un HDD CKD (y, de hecho, cualquier otro comando de escritura CKD), la unidad de control escribe marcas de dirección y/o bytes de sincronización en los espacios vacíos, todos los cuales son "marcas de tiempo" y funcionan de la misma manera que las marcas de servo y los bytes de sincronización en los HDD FBA modernos. El contenido de HA y RO puede estar en un nivel superior, pero en el proceso de escritura, la unidad de control escribe "marcas de tiempo", es decir, realiza un formato de bajo nivel y, en el proceso, completa la información necesaria para el reconocimiento del volumen. El hecho de que un programa, INSTALL de ICKDSF, realice simultáneamente dos "funciones" de formateo de disco, es decir, formateo y partición de bajo nivel, no cambia el hecho de que existen dos funciones. La marca de dirección indica el inicio de un registro CKD, es decir, "indica el inicio de un bloque de grabación", como se utiliza actualmente la frase en nuestra definición de "formateo de bajo nivel". De la misma manera, el campo de sincronización que ubica el inicio de cada campo CKD también es una marca de tiempo. ¿El formato DOS de una FDD no realiza las tres "funciones" de formateo de disco en un programa y en una sola pasada? Por lo tanto, me parece que ciertos comandos de canal, en particular WRO y WCKD, "formatean a bajo nivel" la pista utilizando nuestra definición actual del proceso de formateo de disco. Por favor, explique por qué no. Tom94022 ( discusión ) 21:06, 30 de diciembre de 2010 (UTC) [ responder ]
Necesito localizar y descargar algunos manuales antiguos, pero desde el 2314 IBM ha estado utilizando pistas de servo que no pueden ser formateadas por el cliente. También hay algún formato en los subsistemas DASD modernos que se puede solicitar desde la consola pero no mediante comandos de canal. Esto último es la norma para los subsistemas que simulan 3390 en matrices de discos SCSI. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 18:15, 2 de enero de 2011 (UTC) [ responder ]
No conozco ningún formato de pista de datos en ninguna unidad CKD (o unidad SMD, en realidad) que no se pudiera implementar en todo el "canal". Todas las unidades IBM CKD desde la 3330 hasta la 3390 usaban una superficie servo dedicada. Todas las superficies de datos eran totalmente grabables por el usuario mediante una utilidad de un tipo u otro. Desde una perspectiva de formato, la superficie servo actúa como una pista de reloj, no sustancialmente diferente en función de la pista de reloj en un tambor, es decir, proporciona la marca de índice y el reloj de escritura. El reloj de escritura de la superficie servo es la razón por la que los espacios 3 y 4 en estas unidades posteriores no tienen que tener en cuenta la tolerancia de velocidad: el reloj de escritura es sincrónico con la rotación del husillo. El contenido de algunos de los campos (por ejemplo, el campo ECC o el byte de sincronización) no eran controlables por el usuario, pero el usuario podía hacer que se escribieran y sobrescribieran mediante comandos de canal. Pero el hecho de que el usuario no pudiera reescribir la superficie servo no es más relevante que el hecho de que un usuario no pudiera hacer una marca de índice. Lo que es relevante es que estamos de acuerdo en que la colocación del tiempo que marca el inicio de un bloque es un "formato de bajo nivel" y que esa era una capacidad del usuario en todas las unidades CKD, todas las unidades SMD, la mayoría de las unidades MFM, etc. Es la llegada de los servos integrados lo que cambió esto. Tom94022 ( discusión ) 05:09, 3 de enero de 2011 (UTC) [ responder ]
El punto es que el formateo de bajo nivel incluye la escritura de las pistas del servo, y hay un sentido de giro contrario a las agujas del reloj para hacerlo, ya sea explícitamente o como un efecto secundario. Eso es muy diferente de algo que el usuario puede hacer como parte de una operación más compleja. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 12:55, 3 de enero de 2011 (UTC) [ responder ]
No estoy seguro de que alguien esté de acuerdo contigo en que el "formateo de bajo nivel" incluye la escritura de pistas de servo, pero incluso si lo hace, es solo un paso en el proceso de formateo de bajo nivel utilizando la definición de este artículo . Un paquete de discos 3336 con solo una superficie de servo escrita no tiene marcas de tiempo que definan la ubicación de los bloques de datos o cualquier otra información; sin embargo, cada sistema informático que usaba esos paquetes proporcionaba una utilidad que luego "marcaba las superficies de los discos con marcadores que indicaban el comienzo de un bloque de recodificación... y otra información..." , es decir, completaba el proceso de formateo de bajo nivel tal como lo definimos en este artículo. En los días del 2314, todo era invocable por el usuario, hoy lo es menos o no lo es en absoluto. El hecho de que algunas partes sean invocables por el usuario y otras no solo es digno de mención, pero realmente no ha cambiado nada. Personalmente creo que escribir la información del servo es un paso separado y previo al formateo de bajo nivel, pero eso no cambia el hecho de que el comando INSTALL de la utilidad ISCKSF (o variantes anteriores de la misma) realiza al menos una parte del proceso de formateo de bajo nivel de todas las unidades CKD y todo el formateo de bajo nivel de las primeras unidades CKD hasta la 2319 inclusive. Tom94022 ( discusión ) 23:47 3 enero 2011 (UTC) [ responder ]

¿Bloquear CRC escrito durante el proceso de formateo?

El CRC del bloque depende del contenido del bloque, por lo que, aunque cada bloque puede escribirse con un CRC cuando se formatea un disco en el nivel bajo, el CRC escrito en ese momento no será el CRC del bloque para siempre: cuando el bloque se reescribe, se escribirá un nuevo CRC. Tal vez se deba elegir otra información como ejemplo de lo que se escribe en un formato de bajo nivel. Guy Harris ( discusión ) 23:02 31 may 2012 (UTC) [ responder ]

Pasos para formatear un disco

Resulta un poco hipócrita afirmar que un proceso puede requerir hasta cinco pasos, "media docena o más", sin proporcionar un ejemplo. En su ausencia, sospecho que la mayoría de los procesos de más de tres pasos podrían reducirse a los tres pasos genéricos indicados. A menos que alguien presente un ejemplo que respalde la edición o que se produzca algún debate aquí, sugiero que eliminemos la edición. Tom94022 ( discusión ) 22:43 18 dic 2012 (UTC) [ responder ]

Es engañoso afirmar que una aclaración sin un ejemplo es engañosa. Creí que dar un ejemplo sería demasiado, especialmente porque el ejemplo no quedaría claro sin una explicación considerable de las funciones CKD y VSAM. El caso que tenía en mente es el de zFS para z/OS. El formateo para zFS requiere todos los
  • Formateo de fábrica de los discos.
  • Definición de volumen lógico para el subsistema DASD
  • Formateo del volumen con ICKDSF
  • Asignación de un ESDS para el zFS, lo que implica formatearlo en intervalos de control
  • Formateo del zFS dentro del ESDS
Solo después de haber realizado todo lo anterior, tendrá un zFS que podrá montar. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 15:52, 27 de diciembre de 2012 (UTC) [ responder ]
Gracias por la ilustración. Por cierto, cinco no es "media docena o más", pero sugiero que los cinco pasos que has identificado se ajustan a los tres procesos de la siguiente manera:
  1. Formateo de bajo nivel == Formateo de fábrica de los discos.
  2. Particionado == Definición de volumen lógico para el subsistema DASD Y Formateo del volumen con ICKDSF
  3. Formato de alto nivel == Asignación de un ESDS... Y Formato del zFS dentro del ESDS
Voy a cambiar "pasos" por "procesos" y modificaré tu nota en consecuencia. Tom94022 ( discusión ) 19:30 27 dic 2012 (UTC) [ responder ]
No he revisado el historial, pero recuerdo que cinco eran palabras originales mías y media docena eran modificaciones de otra persona.
Tengo un problema con tu clasificación de ICKDSF como particionamiento; se adapta mejor al formato de alto nivel, ya que escribe las estructuras de datos que necesita el sistema operativo. Además, ICKDSF admite varias operaciones diferentes y es posible que no quieras categorizarlas todas de la misma manera.
Una pregunta que no he investigado es si algún subsistema DASD requiere formatear los discos físicos antes de asignarles volúmenes lógicos.
Si divide esos cinco pasos en tres procesos, debe tener en cuenta que puede haber más de un tipo de cada proceso y que pueden estar intercalados. Además, es posible que desee relegar parte del material a notas al pie.
¿Quieres referencias sobre ICKDSF, HFS y zFS? Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 21:20 4 ene 2013 (UTC) [ responder ]

No tengo idea de qué significa tu edición reciente, "y los pasos de diferentes procesos pueden intercalarse" , por lo que agradecería algún comentario antes de modificarlo o eliminarlo. Tom94022 ( discusión ) 21:40 13 ene 2013 (UTC) [ responder ]

Lo que describiste como procesos son en realidad categorías. Los pasos para preparar un sistema de archivos para su uso no tienen por qué realizarse en el orden sugerido al agruparlos en esas categorías. Por ejemplo, para utilizar el sistema de archivos CMS debes, en este orden:
  • Definir un disco lógico para el subsistema DASD
  • Inicializar el disco lógico con una etiqueta de volumen
  • Definir minidiscos para CP en ese disco lógico
  • Inicializar el minidisco para su uso por parte de CMS
Tenga en cuenta que las acciones que describe como particionamiento se intercalan con las acciones que describe como preparación del disco para el uso del sistema operativo. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 20:07, 15 de enero de 2013 (UTC) [ responder ]
Me parece que los tres primeros puntos son Particionado (o Creación de volumen ) y el último punto es Formateo de alto nivel . Tom94022 ( discusión ) 22:47 15 ene 2013 (UTC) [ responder ]
El desglose es un poco complicado. Algunos comandos ICKDSF relevantes difieren en su lugar en la jerarquía; lo siguiente ignora algunos detalles irrelevantes
  • CPVOLUME crea estructuras de datos en el disco necesarias para CP y se realiza después de INIT.
  • INIT Crea una etiqueta de volumen y se realiza después de INSTALL para los dispositivos relevantes. Tenga en cuenta que también crea una tabla de contenido de volumen (VTOC), que lo coloca en la categoría de formato de alto nivel .
  • INSTALL se utiliza para realizar la configuración básica de nuevos medios en ciertos dispositivos. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 00:48, 17 de enero de 2013 (UTC) [ responder ]
Solo por curiosidad, ¿cuál de esos pasos implica escribir cosas en el disco (consideraría esos pasos como parte del "formateo del disco") y cuál de esos pasos no (es decir, los pasos que implican informar al software sobre cosas que se han hecho en el disco; no consideraría esos como parte del "formateo del disco")? "Inicializar el disco lógico con una etiqueta de volumen" e "Inicializar el minidisco para que lo use CMS" suenan como si escribieran en el disco; ¿"Definir un disco lógico para el subsistema DASD" y "Definir minidiscos para CP en ese disco lógico" lo hacen? "Definir minidiscos para CP en ese disco lógico" podría hacerlo, ya que supongo que CP almacena la información del minidisco en algún lugar del almacenamiento estable, lo que presumiblemente significa en algún lugar del disco. Guy Harris ( discusión ) 22:01, 15 de enero de 2013 (UTC) [ responder ]
La mecánica de definir dispositivos lógicos para el subsistema DASD varía de un proveedor a otro. Los demás pasos siempre implican escribir datos en el DASD. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 00:48, 17 de enero de 2013 (UTC) [ responder ]
Además, el artículo dice que "la creación de particiones crea estructuras de datos que necesita el sistema operativo", por lo que "la creación de particiones" es , en cierto sentido, "preparar el disco para su uso por parte del sistema operativo". Sin embargo, como se describe en el artículo, tanto la creación de particiones como el formateo de alto nivel crean estructuras de datos que necesita el sistema operativo; la creación de particiones escribe una etiqueta de volumen/mapa de particiones/como se llame la estructura de datos en el disco que indica dónde comienzan y terminan las particiones, y el formateo de alto nivel escribe, por lo general, estructuras de datos del sistema de archivos, y ambas son necesarias para el sistema operativo.
La tabla de contenidos de volumen (VTOC) es sin duda parte del sistema de archivos de OS/360 y otros. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 00:48, 17 de enero de 2013 (UTC) [ responder ]
¿Un "volumen" en el sentido de OS/360 y sus sucesores siempre corresponde a un único DASD? Si no, "volumen" en ese sentido podría corresponder de alguna manera a la noción de un sistema de archivos en, por ejemplo, el sentido UN*X (creo que el catálogo cubría varios volúmenes, pero eso podría haber sido de alguna manera equivalente a usar montajes en UN*X - o en versiones más nuevas de NT - para unir subárboles de directorios separados en un solo árbol). "Volumen" en el sentido en el que lo usé cuando me referí a una "etiqueta de volumen" es un mapa de partición en lugar de una estructura de datos del sistema de archivos. Guy Harris ( discusión ) 02:06, 17 de enero de 2013 (UTC) [ responder ]
En ese sentido, un volumen es cualquier cosa a la que el subsistema de canal pueda acceder en una única dirección; para los fines de este hilo, me refiero únicamente a los volúmenes DASD y no al caso de los volúmenes extraíbles. El software de mainframe de IBM requiere que los volúmenes DASD se inicialicen con una etiqueta de volumen y una tabla de contenidos de volumen.
Un factor que complica la situación es que los volúmenes se pueden definir en varios niveles diferentes de una jerarquía. Por ejemplo, un subsistema DASD puede distribuir un volumen en varias unidades físicas y definir varios volúmenes en una sola unidad física, mientras que el componente CP de z/VM puede subdividir un volumen definido por el subsistema DASD en varios minidiscos.
Un volumen reconocido por z/OS puede contener varios sistemas de archivos Unix, y z/OS también puede distribuir un sistema de archivos Unix en varios volúmenes. En el caso de HFS, el formateo se realiza como parte de la asignación, mientras que en el caso de zFS, la asignación realiza un nivel de formateo y un programa de utilidad independiente realiza un formateo adicional sobre ese. En ninguno de los casos existe una opción de formateo rápido; el formateo implica escribir sobre todo el sistema de archivos.
Existe un problema de jerarquía similar con los servidores Linux, en el que se puede utilizar un LVM para definir volúmenes lógicos sobre los volúmenes proporcionados por el subsistema DASD, que están virtualizados. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 19:38, 22 de enero de 2013 (UTC) [ responder ]
Voy a tratar de limpiar el artículo para describir mejor el particionamiento (es decir, describirlo de manera menos vaga que "[crear] estructuras de datos que necesita el sistema operativo"). Guy Harris ( discusión ) 22:12 15 ene 2013 (UTC) [ responder ]
¿Qué tal si reemplazamos el particionamiento por la creación de volúmenes o la administración de volúmenes , es decir, la creación de uno o más volúmenes lógicos a partir de uno o más discos? El particionamiento, un término que creo que proviene del mundo de Microsoft, es una forma de creación de volúmenes que crea uno o más volúmenes lógicos en un disco. En el mundo Unix, un volumen lógico puede abarcar varios discos y, por supuesto, existe RAID, que con frecuencia es una asignación de muchos a muchos. Tom94022 ( discusión ) 22:47, 15 de enero de 2013 (UTC) [ responder ]
El término "particionado" puede ser el primero que se utilizó en el mundo de Microsoft, pero sin duda se utiliza en otros lugares. Apple tiene una nota técnica anterior a OS X que utiliza el término, y la página del manual HP(4) de 4.2BSD, tal como se extrae de este archivo tar, también utiliza el término.
La creación de un volumen lógico a partir de varias particiones puede escribir estructuras de datos en los discos sin formato (si no están simplemente especificados por un archivo de configuración del sistema operativo), pero eso va más allá del nivel de hacer algo en un solo disco. Sin embargo, eso plantea la cuestión de si el "formateo de alto nivel" debería tratarse como formateo de disco , dado que podría escribir en una partición que cubra todo el disco, una partición que cubra parte del disco, un volumen lógico formado por varias partes del disco o un volumen lógico formado por partes de varios discos... Guy Harris ( discusión ) 04:45, 16 de enero de 2013 (UTC) [ responder ]
Creo que la razón por la que estamos teniendo problemas con la semántica en este artículo es que hemos intentado generalizar a partir de los procesos de formateo de discos duros de tipo ST506, que son bastante específicos, en concreto, el BIOS de bajo nivel, el particionamiento FDISK y el formateo de alto nivel Format. Desafortunadamente, creo que eso nos lleva a la investigación original . He buscado material genérico sobre sistemas de archivos para citar, pero sin mucha suerte. La mayoría de las cosas parecen ser sobre este o aquel sistema de archivos, pero nada trata los sistemas de archivos y el formateo asociado de los discos como un tema genérico. Los libros de Tannenbaum, capítulo 6, y Nutt, capítulo 13, podrían funcionar, así que pedí algunas copias usadas en Abebooks. Mientras tanto, me parece que para los fines de este artículo podría no haber una distinción sustancial entre una partición y un volumen lógico, es decir, de manera genérica, los tres procesos necesarios para hacer que una parte o la totalidad de un disco sea utilizable para un sistema informático son:
  1. El formateo de bajo nivel que hace que la unidad de disco física aparezca como bloques contiguos de datos, hoy en día está bien.
  2. Creación de una unidad de volumen lógico que hace que la totalidad o partes de una o más unidades de disco sean visibles para el sistema operativo
  3. Formato de alto nivel que hace que la unidad de volumen lógico sea visible para el sistema de archivos.
Por ahora, supongo que este es mi WP:OR , pero espero encontrar una fuente secundaria a la que podamos hacer referencia en el artículo. El otro enfoque podría ser hablar de cada caso específico, comenzando con el ejemplo FDD/ST506 y luego comparando y contrastando con algunos otros ejemplos comunes, es decir, Optioal, Modern HDD, Linux, etc. Esto último parece demasiado trabajo. Tom94022 ( discusión ) 19:22, 16 de enero de 2013 (UTC) [ responder ]
Uso alternativo de unidad lógica en lugar de volumen lógico para evitar términos ambiguos. Tom94022 ( discusión ) 19:00 19 ene 2013 (UTC) [ responder ]
No utilizaría el término "volumen lógico" en este caso, porque, al menos en algunos sistemas operativos, la creación de particiones de discos y volúmenes lógicos se realiza en capas diferentes: los volúmenes lógicos se crean a partir de particiones de discos. Consulte la página de volúmenes lógicos . Esa página se refiere a "volúmenes físicos", que corresponderían a particiones (o discos completos; también hablan de LUN SCSI, pero, como indica la página de número de unidad lógica , cuando se habla de discos, estos tienden a corresponder a discos individuales; de lo contrario, cuando se habla de otros medios de acceso aleatorio, corresponden a, ejem, volúmenes lógicos en una matriz RAID, donde el volumen lógico es administrado por el controlador RAID en lugar del sistema operativo: "RAID de hardware" frente a "RAID de software").
(Por cierto, también deberíamos evitar el recentismo; UN*X y Windows NT pueden hacer esto de una manera, como lo hicieron algunos sistemas operativos más antiguos, pero los sistemas operativos mainframe tradicionales (e incluso al menos algunas generaciones de minicomputadoras y hardware mainframe ) pueden hacerlo de una manera suficientemente diferente como para que se necesite un poco de trabajo cuidadoso para tener un modelo general que describa a ambos, como, por ejemplo, en algunos de los comentarios de User:Chatul . Y, sí, varios UN*X son sistemas operativos mainframe; por eso dije "tradicionales".) Guy Harris ( discusión ) 20:20 16 ene 2013 (UTC) [ responder ]
¿Deberíamos mencionar la nomenclatura de cortes utilizada en Solaris ? Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 00:48 17 ene 2013 (UTC) [ responder ]
Parece que estamos de acuerdo en que un volumen lógico consiste en una o más particiones (también conocidas como slice o volumen físico) de una o más unidades de disco, donde cualquier partición puede ser la totalidad o parte de una unidad física. La creación de particiones sería un paso opcional en el proceso de creación de un volumen lógico. En el caso más simple, el volumen lógico == volumen físico == unidad de disco duro física. Nuevamente, esto es WP:OR a menos que alguno de nosotros pueda encontrar una fuente secundaria confiable. Tom94022 ( discusión ) 03:44, 17 de enero de 2013 (UTC) [ responder ]
En realidad, creo que, si bien, en cierto sentido, en un equipo que ejecuta un sistema operativo sin un administrador de volúmenes lógicos , una sola partición podría considerarse un "volumen lógico", creo que referirse a ella como un volumen lógico podría confundir a las personas acostumbradas a la noción de que un "volumen lógico" es algo implementado por un software de administrador de volúmenes lógicos y, por lo tanto, que usar el término "volumen lógico" como si se aplicara a todos los sistemas operativos confundiría más de lo que aclararía. Tal vez sea desafortunado que el término "volumen lógico" se haya asociado con grupos de regiones de discos concatenados/en franjas/etc., pero tengo la impresión de que se ha asociado de esa manera. Guy Harris ( discusión ) 07:48, 17 de enero de 2013 (UTC) [ responder ]
Observo que la gestión de volúmenes lógicos no hace referencia a sus discusiones genéricas, pero parece haber caído en nuestra trampa de intentar generalizar a partir de lo específico, por lo que no le doy mucho crédito al artículo como fuente de asociación. Por ejemplo, la Enciclopedia MS-DOS ©1988 (MS-DOS 3.3) incluye la frase: "Por varias razones, los dispositivos de bloques físicos grandes, como los discos fijos, a menudo se dividen lógicamente en dispositivos de bloques lógicos más pequeños..." y entonces era el comando VOL el que "muestra el nombre de un disco o la etiqueta del volumen". Del mismo modo, el diccionario Microsoft de 1999 define partición como "Una porción lógicamente distinta de... un dispositivo de almacenamiento que funciona como si fuera una unidad física" y una unidad lógica como "Un dispositivo nombrado por la lógica de un sistema de software, independientemente de su relación física con el sistema". Por lo tanto, al menos según Microsoft, no es una exageración de dispositivo a volumen y que, de manera genérica, una partición es un volumen lógico. Estoy buscando al menos una fuente más confiable que no sea de Microsoft para este tema y cuando la encuentre, intentaré corregir este artículo, así como el artículo sobre administración de volúmenes lógicos . Gracias por señalar la superposición Tom94022 ( discusión ) 18:08, 19 de enero de 2013 (UTC) [ responder ]

Para que conste, Sistemas operativos modernos, 2.ª edición , A Tanenbaum, ©2001, sección 3.4.2, Formateo de disco , define el siguiente proceso genérico de tres pasos:

"Antes de poder utilizar un disco, cada plato debe recibir un formato de bajo nivel realizado mediante software.
...
Una vez finalizado el formateo de bajo nivel, se realiza la partición del disco. Lógicamente, cada partición es como un disco independiente.
...
El paso final para preparar un disco para su uso es realizar un formateo de alto nivel de cada partición por separado. ..."

Tanenbaum no abordó sistemas más complejos como UNIX, donde el volumen lógico puede abarcar discos físicos, ni RAID, ni administración de datos complejos, pero parece ser una fuente confiable para un proceso de tres pasos. Usar la creación de unidades lógicas con una explicación para el proceso 2 en lugar de la creación de particiones parece, bueno, lógico  :-) sin ser OR . Tom94022 ( discusión ) 22:21, 28 de enero de 2013 (UTC) [ responder ]

¿Formato de documento para citas?

Hay varios manuales de IBM disponibles en línea en varios formatos, por ejemplo, BookManager, HTML, PDF. Supongo que la mayoría de los lectores de Wiki pueden manejar tanto HTML como PDF, pero cuál es preferible en las citas. Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 01:18, 19 de mayo de 2013 (UTC) [ responder ]

"la mayoría de los lectores de Wiki pueden manejar tanto HTML como PDF" Si por "lectores" te refieres a "humanos que leen el artículo", es probable que sea cierto, aunque es posible que tengan que haber descargado Adobe Reader si están usando Windows. Sin embargo, es posible que algunos PDF no aparezcan en un lector si se hace clic en ellos, en cuyo caso el humano tendría que abrir el directorio de descargas y abrirlo.
"pero que es preferible en las citas" En igualdad de condiciones, HTML es preferible (es más probable que pueda vincular a la parte específica del manual, podría visualizarse más rápido), que es presumiblemente la razón por la que es el formato predeterminado para las citas (aunque plantillas como {{cite web}} pueden inferir PDF a partir de la extensión en la URL. Guy Harris ( discusión ) 01:34, 19 de mayo de 2013 (UTC) [ responder ]
Quizás quieras leer Wikipedia:Citar fuentes , que enfatiza el contenido de una cita sin hacer recomendaciones sobre el contenido de ningún enlace. Estoy de acuerdo con Guy Harris en que si un enlace está disponible en varios formatos, el orden preferido para los tres que mencionas es HTML, PDF, BookManager. Tom94022 ( discusión ) 04:51 19 may 2013 (UTC) [ responder ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de modificar 3 enlaces externos en Formateo de disco . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

Cuando haya terminado de revisar mis cambios, configure el parámetro marcado a continuación como verdadero o no para informar a los demás (documentación en ).{{Sourcecheck}}

Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— InternetArchiveBot ( Reportar error ) 22:34, 13 de diciembre de 2016 (UTC) [ responder ]

Correcciones en disquetes 0xE5 y 8"

Los disquetes de 8" no venían con el formato "CP/M", sino que se compraban con el formato "IBM 3740". Digital Research simplemente aprovechó el hecho de que IBM eligió llenar los sectores de la pista 2 (el directorio CP/M) con caracteres EBCDIC "V", y estableció así la convención de que 0xE5 significaba una entrada de directorio CP/M vacía. El formato IBM 3740 tenía caracteres EBCDIC SPACE (0x40) en los sectores de la pista 0, si mal no recuerdo, que creo que era donde IBM tenía su directorio. Pero la mayoría de los nuevos formatos CP/M (8" DD, 5.25", etc.) tendían a llenar todos los sectores con 0xE5 y evitar la necesidad de saber dónde se ubicaría el directorio CP/M. Por lo tanto, el 0xE5 se originó en los mainframes de IBM, pero fue perpetuado en el mundo de las PC (pre-IBM) por Digital Research (y quizás otros).

Durgadas311 (discusión) 15:03 1 mar 2017 (UTC) [ responder ]

Siéntete libre de hacer las correcciones que consideres necesarias , preferiblemente con una cita . Guy Harris ( discusión ) 16:50 1 mar 2017 (UTC) [ responder ]

Mantener este artículo actualizado

Tal vez este artículo deba dividirse en Formateo de discos e Historial del formateo de discos, suponiendo que podamos llegar a un consenso sobre qué medios y hardware están obsoletos y agregar la nota de encabezamiento correspondiente. patsw ( discusión ) 18:03, 4 de agosto de 2018 (UTC) [ responder ]

Definición de formato de alto nivel

La definición actual de formato de alto nivel es una reformulación de la referencia de Tannebaum. La pregunta es si las estructuras posteriores creadas dentro de un sistema de archivos constituyen un formato de alto nivel tal como se utiliza la frase en la técnica. Un ejemplo de tales estructuras son los numerosos formatos de bases de datos utilizados en varios sistemas de archivos, por ejemplo, los archivos de bases de datos cuya construcción, según tengo entendido, no se encuentra en la técnica , se denomina formato de alto nivel; por lo general, se trata simplemente de formato. En consecuencia, eliminé "sistemas de archivos que contienen" de la definición. ¿Comentarios? Tom94022 ( discusión ) 22:14, 4 de octubre de 2021 (UTC) [ responder ]

Un sistema de archivos en el sentido en que se lo utiliza generalmente puede existir dentro de un archivo de imagen de disco en otro sistema de archivos (el mismo tipo de sistema de archivos o un tipo de sistema de archivos diferente). Por ejemplo, las imágenes ISO se utilizan para instalar sistemas operativos en máquinas virtuales y las aplicaciones macOS suelen distribuirse en archivos ".dmg" que contienen un sistema de archivos HFS+ .
Es posible que eso sea a lo que se refería cuando se decía "sistemas de archivos que contienen". Guy Harris ( discusión ) 22:21 4 oct 2021 (UTC) [ responder ]
Un disco puede formatearse sin un sistema de archivos, por ejemplo, un disco propiedad de CP en VM . Además, un sistema de archivos puede existir dentro de otro sistema de archivos, por ejemplo, un zFS [a] en z/OS . Creo que el término formateo de alto nivel se aplica a ambos casos. No estaba considerando [b] el caso de una imagen de disco, por ejemplo, un archivo ISO que contiene un sistema de archivos. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 14:37, 5 de octubre de 2021 (UTC) [ responder ]
No creo que una imagen ISO de un disco sea un sistema de archivos, sino un archivo que contiene una imagen. Tom94022 ( discusión ) 18:54, 6 de octubre de 2021 (UTC) [ responder ]
No todos los archivos de "imagen de disco" son "imágenes de disco" en el sentido de que son una copia byte a byte de un CD/DVD físico o un HDD/SSD físico. macOS , por ejemplo, tiene la aplicación GUI Disk Utility y la utilidad de línea de comandos hdiutil, que puede crear una imagen de disco vacía y particionada, que luego se puede "adjuntar", de modo que las particiones aparezcan como dispositivos de disco con /deventradas. Luego, puede usar cualquier herramienta que pueda hacer un "formateo de alto nivel" de un HDD/SSD real para hacer un "formateo de alto nivel" del disco "falso"; cada escritura en el dispositivo de disco se reenvía a un proceso demonio que las realiza escribiendo en un archivo. No hay discos involucrados excepto los discos que contienen el sistema de archivos en el que se encuentra el archivo. Guy Harris ( discusión ) 21:27, 6 de octubre de 2021 (UTC) [ responder ]
Estoy de acuerdo, pero no me parece que crear dichas imágenes equivalga a "crear el formato del sistema de archivos dentro de una partición de disco o un volumen lógico", que es la referencia de Tanenbaum. El sistema de archivos ya creado utiliza la imagen tal como la entiendo. Tom94022 ( discusión ) 22:26 13 oct 2021 (UTC) [ responder ]
¿Qué quiere decir aquí con "sistema de archivos"? Si se copiara una imagen ISO byte a byte en un CD, ¿contendría ese CD un sistema de archivos? Si es así, entonces presumiblemente la imagen ISO también contendrá un sistema de archivos. Si se copiara un archivo de imagen de disco de Apple que contuviera un sistema de archivos HFS+ o APFS byte a byte en una partición de disco, ¿contendría esa partición de disco un sistema de archivos? Si es así, entonces presumiblemente el archivo de imagen de disco también contendría un sistema de archivos.
Ahora bien, si se quiere decir que escribir estructuras de datos del sistema de archivos - "crear el formato del sistema de archivos" - en una partición de disco o un volumen lógico constituye un "formateo de alto nivel", pero escribir estructuras de datos del sistema de archivos - "crear el formato del sistema de archivos" - dentro de un archivo no, eso es diferente. Tanto "crear el formato del sistema de archivos", como "formatear" podrían, supongo, restringirse a operaciones que escriben directamente en un disco o partición en lugar de escribir en bloques de un archivo dentro de un sistema de archivos existente. Guy Harris ( discusión ) 23:09 13 oct 2021 (UTC) [ responder ]
Este artículo en el lede define el formateo de disco como El formateo de disco es el proceso de preparar un dispositivo de almacenamiento de datos... para su uso inicial. En algunos casos, la operación de formateo también puede crear uno o más sistemas de archivos nuevos. El formateo de alto nivel es el tercer paso del proceso que, en mi opinión, lo restringe a las operaciones que escriben directamente en un disco o partición en lugar de escribir en bloques de un archivo dentro de un sistema de archivos existente. Por cierto, la cita del lede anterior admite la inclusión de IDKDSF como formateo de alto nivel, aunque IBM no utiliza el término explícitamente. Tom94022 ( discusión ) 19:52, 14 de octubre de 2021 (UTC) [ responder ]


Un disco formateado sin sistema de archivos no ha sido formateado de alto nivel en el sentido común del término. Al revisar varias publicaciones relevantes de IBM, no pude encontrar ninguna fuente confiable que describiera el formato de VSAM Linear Data Set (LDS) como formato de alto nivel o que fuera incluso un sistema de archivos, por lo que parece que no es un sistema de archivos en el sentido común de ese término, sino que representa un formato posterior dentro de un sistema de archivos ( z/OS ) que hace que los contenidos formateados estén disponibles para, en este ejemplo, un método de acceso de IBM, pero de manera más general, este es un caso de formato posterior dentro de un sistema de archivos que hace que los contenidos estén disponibles para una aplicación (o método de acceso) como, por ejemplo, los numerosos archivos de base de datos que deben formatearse antes de que una base de datos pueda acceder a ellos. Propongo agregar un lenguaje que cubra el formato posterior a la sección para cubrir tanto el lenguaje agregado recientemente sobre VSAM Linear Data Set (LDS) como los archivos de base de datos. Tom94022 ( discusión ) 18:54, 6 de octubre de 2021 (UTC) [ responder ]
¿Cómo se llamaría entonces el proceso de escritura de R0 en cada pista? Desde luego, no es el tipo de formato que se realiza en la fábrica y no coincide con la descripción del formato de bajo nivel que se incluye en el artículo.
El LDS que contiene un zFS existe dentro de un sistema de archivos, por lo que el zFS existe dentro de un sistema de archivos. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 23:57, 6 de octubre de 2021 (UTC) [ responder ]
Yo llamaría a los diversos procesos que IBM describe en IDKDSF como formateo de alto nivel , aunque IBM no lo haga. Específicamente en la página 74 para dispositivos CKD y la página 363 para dispositivos FBA, IBM revela el "formateo" necesario "para su entorno operativo" utilizando los comandos INIT, CPVOLUME o AIXVOL según el entorno; para responder a su pregunta, el comando INSTALL escribe la dirección de inicio y el registro 0 en cada pista de ciertos volúmenes. El problema es semántico, ya que IBM usa algunos lenguajes de formas diferentes al resto de la industria y no puedo encontrar nada que me lleve a concluir que "formatear un LDS que contiene un zFS" equivale a crear un sistema de archivos más de lo que crear un archivo o archivos de base de datos equivale a crear un sistema de archivos. Tom94022 ( discusión ) 22:26, ​​13 de octubre de 2021 (UTC) [ responder ]

Aquí hay una definición del diccionario:

Definiciones de formato de alto nivel
(sustantivo) (informática) el formato del directorio raíz y las tablas de asignación de archivos y otras configuraciones básicas
tipo de:
formato de datos, formateo de datos, formato, formateo
la organización de la información según especificaciones preestablecidas (generalmente para procesamiento informático)

A menos que haya más discusión, voy a revisar más la sección para limitar el formato de alto nivel a las operaciones que escriben directamente en un volumen o partición en lugar de escribir en bloques de un archivo dentro de un sistema de archivos existente e incluir solo los comandos IDKDSF y el lenguaje como tal para IBM. Tom94022 ( discusión ) 19:16, 16 de octubre de 2021 (UTC) [ responder ]

Pueden existir un directorio raíz y una tabla de asignación de archivos dentro de un archivo simple:
$  hdiutil  create  -megabytes 1 .5 -fs MS-DOS /tmp/fatimage    creado:  /tmp/fatimage.dmg$  archivo  /tmp/fatimage.dmg  /tmp/fatimage.dmg: sector de arranque  DOS/MBR ; partición 1 : ID = 0xb, CHS de inicio ( 0x3ff,254,63 ) , CHS de fin ( 0x3ff,254,63 ) , sector de inicio 1 , 3071 sectores, tabla de particiones extendida ( última )
$ hdiutil adjuntar /tmp/fatimage.dmg
/dev/disk2 FDisk_partition_scheme
/dev/disk2s1 DOS_FAT_32 /Volumes/NO NAME                           $ echo "Este es un archivo dentro de un sistema de archivos FAT dentro de un archivo " >/Volumes/NO\NAME/file.txt   $  ls  /Volumes/NO \ NOMBRE/archivo.txt$  grep 'Este es un archivo' /Volumes/NO \ NAME/file.txt
Este es un archivo dentro de un sistema de archivos FAT dentro de un archivo
$ grep 'Este es un archivo' /tmp/fatimage.dmg                   El archivo
binario  /tmp/fatimage.dmg  coincide$  grep 'Esto no es un archivo' /tmp/fatimage.dmg  $  ls  -l  /tmp/fatimage.dmg-rw-r--r--@ 1 rueda de harris 1572864 16 de octubre 14:18 /tmp/fatimage.dmg        $  mount | egrep disco2   /dev/disk2s1  en  /Volumes/NO  NAME ( msdos, local, nodev, nosuid, noowners, montado por gharris )
El archivo {{mono}/tmp/fatimage.dmg}} es, como se muestra arriba, un archivo normal y corriente, es decir, al ser un UNIX(R) ( macOS Big Sur ), es una matriz de bytes buscables, tal como lo son /etc/passwd o /bin/cat o....
También contiene un directorio raíz y una tabla de asignación de archivos, ya que su contenido no es un archivo de texto que proporciona nombres de usuario, ID de usuario, etc. o un archivo Mach-O que contiene el código ejecutable del comando cat o..., son un sistema de archivos FAT. También contiene, en ese directorio raíz, un archivo llamado file.txt , cuyo contenido es la cadena "Este es un archivo dentro de un sistema de archivos FAT dentro de un archivo "; si busco esa cadena en el archivo simple /Volumes/NO NAME/file.txt , aparece, y si busco esa cadena en el archivo simple /tmp/fatimage.dmg , aparece.
Y si cambio el archivo en el sistema de archivos FAT:
$ echo "Este es realmente un archivo dentro de un sistema de archivos FAT dentro de un archivo" >/Volumes/NO\NAME/file.txt   $  grep 'Este es un archivo' /Volumes/NO \ NAME/file.txt  $  grep 'Este es un archivo' /tmp/fatimage.dmg  $  grep 'Esto es realmente un archivo' /Volumes/NO \ NAME/file.txt  Este  es  realmente  un  archivo  dentro de  un sistema de archivos  FAT dentro de un archivo     $  grep 'Esto es realmente un archivo' /tmp/fatimage.dmg   El archivo
binario  /tmp/fatimage.dmg  coincide
El contenido del archivo de imagen cambia.
La definición de "formateo de alto nivel" que ofrece dictionary.com no dice nada sobre discos/unidades o particiones dentro de un disco/unidad, lo cual es bueno, ya que existe un objeto ( /tmp/fatimage.dmg en mi máquina) que no es un disco/unidad ni una partición dentro de un disco/unidad, pero que sin embargo contiene un directorio raíz y una tabla de asignación de archivos. Sucede que contiene particiones, al igual que un disco/unidad puede contener particiones, pero no es algo en la forma física de un disco/unidad, es un objeto que vive dentro de un sistema de archivos APFS , cuyo contenido es administrado en última instancia por APFS, y las lecturas y escrituras desde y hacia el "disco/unidad" pasan por diskimages-helper :
$  ps  -ef | egrep diskimages-helper 501 21431 1 0 2 :41PM ?? 0 :00.03 /Sistema/Biblioteca/PrivateFrameworks/DiskImages.framework/Recursos/diskimages-helper -uuid EF438C6A-EFCF-4613-BF3F-707A47DA7994 -post-exec 4
Por lo tanto, "revisar más la sección para limitar el formateo de alto nivel a operaciones que escriben directamente en un volumen o partición en lugar de escribir en bloques de un archivo dentro de un sistema de archivos existente" está bien siempre y cuando se reconozca que "un volumen o partición" podría existir dentro de un archivo dentro de un sistema de archivos existente, lo que significa que "[escribir] directamente en un volumen o partición" podría, en última instancia, convertirse en "escribir en bloques de un archivo dentro de un sistema de archivos existente". (Bueno, técnicamente, en mi ejemplo, la escritura se hizo directamente en un archivo dentro de un sistema de archivos existente, como lo hizo hdiutil create , antes de que el archivo de imagen de disco se adjuntara mediante hdiutil attached . Puede ser que haya una manera de crear un archivo vacío, adjuntarlo de manera que haya un archivo de dispositivo en /dev para él y diskimages-helper implemente lecturas desde y escrituras en ese archivo de dispositivo como lecturas desde y escrituras en el archivo, y luego ejecute newfs_msdos en ese archivo de dispositivo para colocar el directorio raíz y la tabla de asignación de archivos en el archivo subyacente, y luego monte ese archivo de dispositivo). Guy Harris ( discusión ) 21:51, 16 de octubre de 2021 (UTC) [ responder ]
El párrafo inicial del artículo describe tres pasos de "formato": "formato de bajo nivel", "particionamiento" y "formato de alto nivel".
Los dos últimos pasos se pueden realizar, para la mayoría de los sistemas de archivos, en cualquier cosa a la que se pueda acceder como una matriz buscable de bloques de longitud fija o, para un "formato de alto nivel", en una partición de algo en lo que se ha realizado un "particionado", por lo que se pueden realizar en un archivo simple en un sistema de archivos "los archivos son matrices buscables de bytes" (por ejemplo, Unix y sistemas inspirados en Unix en ese sentido, como MS-DOS, Windows, etc.) mediante un software que divide ese archivo en bloques de longitud fija, del mismo modo que se pueden realizar en un disco/unidad al que se puede acceder como una matriz buscable de bloques de longitud fija.
Para las unidades CKD y los sistemas de archivos que las utilizan, las cosas pueden ser diferentes (aunque tengo la impresión de que, actualmente, una "unidad CKD" es un dispositivo virtual implementado sobre una unidad que es una matriz buscable de bloques de longitud fija).
(Aquí dejamos de lado más capas de virtualización de bloques ).
Por lo tanto, lo único que es específico de los discos en el "formateo de discos" es el formateo de bajo nivel. Guy Harris ( discusión ) 22:22 16 oct 2021 (UTC) [ responder ]
Para CKD, el hardware subyacente es una matriz de volúmenes orientados a sectores, y un volumen visto por el canal puede estar distribuido en partes de múltiples volúmenes físicos. Como lo ve el SO, un sistema de archivos es una secuencia de bloques que se puede buscar y que no necesita tener un tamaño uniforme, es decir, el directorio de un PDS tiene bloques de longitud fija (KL=8, DL=256) mientras que los miembros tienen características diferentes. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 14:29, 17 de octubre de 2021 (UTC) [ responder ]
No hay nada en esa definición que la limite a existir directamente en un disco o partición; se aplica igualmente al formateo de un sistema de archivos que existe en un archivo de un sistema de archivos que lo contiene. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 14:29, 17 de octubre de 2021 (UTC) [ responder ]

Lamento tener que repetir esto, pero arriba señalé que:

Este artículo define el formateo de disco como "El formateo de disco es el proceso de preparación de un dispositivo de almacenamiento de datos... para su uso inicial. En algunos casos, la operación de formateo también puede crear uno o más sistemas de archivos nuevos". El formateo de alto nivel es el tercer paso del proceso, que creo que lo restringe a operaciones que escriben directamente en un disco o partición en lugar de escribir en bloques de un archivo dentro de un sistema de archivos existente.

Parece que todo el formato que analizan Chatul y Harris es un formato adicional al que se realizó para que un dispositivo de almacenamiento estuviera disponible inicialmente para el sistema. Este formato adicional no es un formato de alto nivel , tal como lo define Tanenbaum y como se indica en el nivel. El ejemplo de UNIX publicado por Harris es un ejemplo de formato adicional mucho después de que el medio de almacenamiento se puso a disposición del sistema mediante el uso de un conjunto muy diferente de comandos, como fdisk, mkfs, format, etc. Consulte "Cómo instalar una nueva unidad de disco en UNIX". IDKDSF describe los comandos de IBM, incluida su versión para UNIX.

En realidad, se trata de un problema de semántica: tanto el formateo de disco como el formateo de alto nivel tienen significados comunes muy específicos, que es la forma en que está escrito este artículo. ¡Todos tienen que ver con la inicialización! No tendría ningún problema con una adición al encabezado que diga que después de formatear el disco, el formateo adicional puede crear estructuras especializadas dentro de un sistema de archivos, como archivos de base de datos o incluso sistemas de archivos adicionales o palabras a tal efecto, por supuesto, con fuentes confiables adecuadas. Pero sugiero que es O o POV para expandir el significado del formateo de disco o del formateo de alto nivel más allá de su uso común como inicialización de medios de almacenamiento. Tom94022 ( discusión ) 23:00, 17 de octubre de 2021 (UTC) [ responder ]

"Parece que todo el formateo que comentaron Chatul y Harris es un formateo adicional al que se hizo para que un dispositivo de almacenamiento estuviera inicialmente disponible para el sistema". El único formateo absolutamente necesario para que un dispositivo de almacenamiento esté inicialmente disponible para el sistema, en el sentido de que el sistema pueda leer y escribir en el dispositivo, es el formateo de bajo nivel. El dispositivo de almacenamiento queda entonces disponible para que el sistema realice particiones o formateo de alto nivel en él. Por lo tanto, dado que las operaciones de formateo que estaba comentando eran particionamiento y formateo de alto nivel, su afirmación es verdadera, pero no necesariamente en el sentido que usted pretendía que fuera verdadera.
"El ejemplo de UNIX publicado por Harris es un ejemplo de formateo adicional mucho después de que el medio de almacenamiento se puso a disposición del sistema mediante el uso de un conjunto muy diferente de comandos como fdisk, mkfs, format, etc." Exactamente. fdisk es un ejemplo de un comando que realiza particiones, y mkfs /newfs (y los comandos dependientes del tipo de sistema de archivos que ejecutan) son los comandos que se utilizan para crear sistemas de archivos en un sistema UN*X, incluido el "formateo de alto nivel" al ejecutarlo en un medio de almacenamiento en lugar de, por ejemplo, un archivo simple. No es como si tuviera que tener un medio de almacenamiento que ya haya sido particionado por alguna herramienta que no sea, digamos, fdisk, y que tenga un sistema de archivos colocado en él por alguna herramienta que no sea, digamos, mkfs/newfs, para poder usar fdisk o mkfs/newfs.
Entonces, tal vez el "formato de alto nivel" debería describirse como el proceso de escribir un nuevo sistema de archivos en un medio de almacenamiento , es decir, mkfs/newfs es un comando para escribir un nuevo sistema de archivos y, cuando se le entrega un archivo especial para la partición del disco de un dispositivo de almacenamiento como el archivo en el que escribir, realiza un "formato de alto nivel".
En cuanto a "particionar", el artículo lo tergiversó, diciendo que "[hacía] que el dispositivo de almacenamiento de datos fuera visible para un sistema operativo" y "[permitía] el acceso por parte de un sistema operativo". Eso no es lo que decía la referencia de Tanenbaum, y no está claro qué quería decir. Parte de lo que hace, como el propio nombre indica, es dividir el disco en múltiples particiones, es decir, subdispositivos. Dependiendo del sistema y la forma en que arranca, también podría implicar escribir información para permitir que un sistema operativo se inicie desde el medio, pero eso no tiene nada que ver con "particionar" per se . También puede ser que algunos sistemas operativos requieran que haya una tabla de particiones en un dispositivo para poder acceder a los sistemas de archivos en el dispositivo, pero eso no es cierto para todos los sistemas operativos (los primeros sistemas UNIX tenían la tabla de particiones compilada en el controlador del dispositivo , y se podía configurar un sistema de archivos en una partición que comenzaba en el primer sector de la unidad y se extendía hasta el final de la unidad). Y, dado que el "particionado" a menudo lo realizan programas que se ejecutan bajo un sistema operativo , las unidades no particionadas son accesibles al sistema operativo al menos en algún sentido.
Lo he limpiado un poco, pero necesita más trabajo. Creo que la misma utilidad particiona las unidades y agrega información de arranque en la mayoría de los sistemas operativos UN*X y en Windows, pero, en los sistemas operativos mainframe de IBM, ¿existe siquiera la noción de "particionar" una unidad en el sentido actual de UN*X/Windows, con la unidad misma conteniendo información sobre las particiones (en lugar de en el sentido de minidisco) y, si es así, ¿lo hace el mismo programa que escribe la información de IPL?
Una vez que se haya solucionado ese problema, podemos preocuparnos por cómo llamar "particionado" de un objeto arbitrario (incluido un objeto dentro de un sistema de archivos) y cómo llamar a esa operación cuando se realiza específicamente en un dispositivo de almacenamiento de datos. Guy Harris ( discusión ) 02:20, 18 de octubre de 2021 (UTC) [ responder ]

Puede ser útil tener en cuenta que existe una división entre el "formato de bajo nivel" y todas las operaciones de inicialización de almacenamiento posteriores.

El "formateo de bajo nivel" es específico del tipo de dispositivo y del dispositivo. En los sistemas modernos, no es algo que un ordenador host haga normalmente, o quizás ni siquiera pueda hacer; se realiza en la fábrica. Como señala el artículo, al menos algunos sistemas más antiguos pueden realizar un formateo de bajo nivel. El formateo de bajo nivel no se realiza en un volumen lógico , sino en un dispositivo físico. No estoy seguro de si la configuración de mapas de bloques defectuosos, una capa de traducción flash , etc. sería el "formateo de bajo nivel" que se realiza para un SSD.

El formateo de bajo nivel a un dispositivo conectado directamente generalmente es suficiente para permitir que el host al que está conectada la unidad (o al que está conectada la controladora del dispositivo) lea y escriba directamente en el dispositivo; no se necesitan operaciones de formateo posteriores para eso (dado que las utilidades que realizan operaciones de formateo posteriores se ejecutan en el host y realizan esas operaciones de lectura y escritura).

Las utilidades que realizan operaciones después del formateo de bajo nivel esperan un dispositivo abstracto que tenga una secuencia de bloques accesibles de forma individual y aleatoria. Esa abstracción podría ser proporcionada por el controlador del disco, para dispositivos cuyo direccionamiento de hardware nativo es cilindro/cabeza/sector, con el controlador realizando las operaciones de división y módulo necesarias para convertir entre un número de bloque a cilindro/cabeza/sector; ese controlador también podría realizar la asignación de bloques defectuosos. Otros dispositivos, como los dispositivos SCSI, hacen eso en el controlador.

Además, un controlador RAID o un administrador de volúmenes lógicos pueden proporcionar una abstracción de este tipo, construida sobre la abstracción anterior, para dispositivos conectados directamente al host o al controlador RAID. Un controlador en una red de canal de fibra puede hacer lo mismo con los dispositivos conectados a la red de canal de fibra para beneficio de los hosts conectados a esa red.

Además, un dispositivo en una red de canal de fibra puede proporcionar esa abstracción sobre contenedores similares a archivos dentro de un sistema de archivos en el dispositivo; eso es lo que hacen los dispositivos de NetApp, y probablemente haya otros proveedores que hagan lo mismo. ("Similares a archivos" porque, según recuerdo, no tienen entradas de directorio del sistema de archivos que apunten a ellos, pero son contenedores extensibles de longitud variable al igual que los archivos y directorios).

Y, además, así es como se ve la unidad C: en una máquina Windows que tengo:

$  ls  -ll  ~/Documentos/Máquinas virtuales / Windows 10 Pro 64 -bit.vmwarevm / Disco virtual * .vmdk-rw-r--r-- 1 gharris admin 4084006912 16 oct 16 :07 /Usuarios/gharris/Documentos/ Máquinas virtuales/Windows 10 Pro 64 -bit.vmwarevm/Virtual Disk-s001.vmdk             -rw-r--r-- 1 gharris admin 4261937152 16 oct 16 :07 /Usuarios/gharris/Documentos/ Máquinas virtuales/Windows 10 Pro 64 -bit.vmwarevm/Virtual Disk-s002.vmdk             -rw-r--r-- 1 gharris admin 4236443648 16 oct 16 :07 /Usuarios/gharris/Documentos/ Máquinas virtuales/Windows 10 Pro 64 -bit.vmwarevm/Virtual Disk-s003.vmdk             -rw-r--r-- 1 gharris admin 4253745152 16 oct 16 :07 /Usuarios/gharris/Documentos/ Máquinas virtuales/Windows 10 Pro 64 -bit.vmwarevm/Virtual Disk-s004.vmdk             -rw-r--r-- 1 gharris admin 4261937152 16 oct 16 :07 /Usuarios/gharris/Documentos/ Máquinas virtuales/Windows 10 Pro 64 -bit.vmwarevm/Disco virtual -s005.vmdk             -rw-r--r-- 1 gharris admin 4261937152 16 oct 16 :07 /Usuarios/gharris/Documentos/ Máquinas virtuales/Windows 10 Pro 64 -bit.vmwarevm/Disco virtual -s006.vmdk             ...

Ese "disco" fue particionado y el instalador de Windows 10 de Microsoft realizó un formateo de alto nivel, probablemente operando bajo la impresión de que simplemente estaba escribiendo en un disco duro común (o SSD; los archivos en cuestión residen en un SSD, pero no sé si VMware pretende que el controlador de disco está ejecutando un HDD o un SDD en ese caso). Es decir, además del formateo de bajo nivel, ese "disco" probablemente se inicializó de la misma manera que se inicializaría un disco real, por un software que probablemente (excepto tal vez a nivel del controlador, si se realiza alguna paravirtualización ) no tiene idea de que está inicializando la unidad de una VM en lugar de una unidad real.

Entonces, incluso si ignoramos las imágenes de disco en el sentido de macOS, todos los pasos posteriores al "formato de bajo nivel" se pueden realizar escribiendo en lo que el software que realiza las operaciones piensa que es un disco, o al menos parece un disco, incluso si está hecho de varios discos, o de un objeto similar a un archivo, o de uno o más archivos, o....

Es decir, el primer párrafo del artículo podría afirmar que "El formateo de un disco es el proceso de preparación de un dispositivo de almacenamiento de datos, como una unidad de disco duro, una unidad de estado sólido, un disquete o una unidad flash USB para su uso inicial", pero las secciones 2.3 y 2.4 del artículo a menudo se aplican a un "dispositivo" de almacenamiento de datos que es más complicado que un HDD/SDD/FDD (una "unidad flash USB" es simplemente un SSD USB). Esas operaciones se pueden aplicar a un solo dispositivo, pero no hay garantía de que se estén aplicando a un solo dispositivo en lugar de a un "dispositivo" abstracto más complicado.

(Y tal vez se requiera aquí algo más que un libro de texto de 2001, ya que 1) algunas de las tecnologías que mencioné que implementan esas abstracciones eran bastante nuevas en 2001 o aún no se habían implementado en 2001 y 2) los libros de texto destinados a estudiantes universitarios simplifican el tema: su descripción de "particionamiento" es bastante específica de la PC (y habla de "Pentium", probablemente para simplificar aún más el tema para los novatos), y su descripción de "formateo de alto nivel" omite el paso de "instalar el sistema operativo en el nuevo y brillante sistema de archivos" para organizar que "en este punto se puede iniciar el sistema").

Entonces, yo diría que, a menos que la cantidad de veces que una matriz RAID/dispositivo virtualizado en una red FC/dispositivo virtualizado provisto por un hipervisor se esté particionando y una o más particiones tengan sistemas de archivos escritos en ellas sea insignificante (incluso teniendo en cuenta que hay muchos servidores grandes, incluso si la mayoría de las computadoras más grandes que las tabletas no son servidores, es decir, los servidores son lo suficientemente importantes como para que no crea que se los pueda descartar), yo diría que el artículo debería hablar de particionamiento y "formateo de alto nivel" realizado en un "volumen" o algún término similar que no implique que sea un solo HDD o SDD físico.

Y tal vez necesitemos hacer una distinción entre "particionar" y "hacer que un volumen sea arrancable", ya que 1) "particionar" no es suficiente para hacer que un volumen sea arrancable, ya que, por ejemplo, un volumen MBR con un bloque de arranque y un montón de sistemas de archivos vacíos no tiene nada para arrancar y 2) "particionar" no siempre es necesario para hacer que un volumen sea arrancable, ya que, al menos para algunos sistemas operativos, podría ser posible simplemente poner un sistema de archivos que contenga un sistema operativo arrancable directamente en un disco no particionado.

En cuanto a un zFS , ¿se da el caso de que un DASD se inicialice con zFS y no con ningún otro sistema de archivos? Si no es así, tal vez se podría argumentar que la instalación de un zFS, si no se realiza como parte del proceso de inicialización de un volumen para su uso en z/OS, podría no contar como "formateo de alto nivel" si el "formateo de alto nivel" se define como el proceso de "configurar un nuevo sistema de archivos" cuando se realiza en un volumen (en el sentido de "algo que un conjunto de firmware y software, que se ejecuta en alguna combinación de la computadora host y posiblemente dispositivos en una red, hace que parezca algo así como un disco". Guy Harris ( discusión ) 06:24, 18 de octubre de 2021 (UTC) [ responder ]

El particionamiento no tiene por qué hacer que una partición sea arrancable; una partición puede ser solo de datos. En PC-DOS y OS/2 hay un máximo de 4 particiones, una de las cuales puede ser una partición lógica extendida y, a su vez, estar particionada. A modo de ejemplo, en mi PC principal tengo 5 particiones arrancables y 7 particiones solo de datos, la mayoría de las cuales son unidades lógicas en la partición lógica extendida. ArcaOS, un OS/2 renombrado, normalmente se instala en JFS , lo que requiere que el Logical Volume Manager (LVM) de IBM realice el particionamiento.
ICKDSF inicializa un volumen con un VTOC, momento en el que z/OS puede asignar un conjunto de datos heredado en el volumen, pero no puede almacenar un archivo Unix en él. Para almacenar un archivo Unix en el volumen, la instalación debe crear un sistema de archivos [c] en el volumen y montar ese sistema de archivos. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 03:48, 19 de octubre de 2021 (UTC) [ responder ]

Si se puede encontrar algo más que un libro de texto de 2001, el artículo podría ampliarse para incluir gran parte de los dictámenes de esta charla, pero hasta que haya una fuente confiable para una definición diferente de Formateo de disco y sus tres pasos, sugiero que este artículo se limite a esa referencia. Francamente, dudo que exista una definición más "moderna". Para que conste, he buscado una y no he encontrado ninguna, y lo que he encontrado respalda el artículo actual, que básicamente limita los términos a esos tres pasos en la preparación de un medio de almacenamiento físico para el uso inicial para el cual los comandos específicos del SO para el paso 3, "formateo de alto nivel", se identifican aquí arriba (por ejemplo, fdisk, mkfs, format, INIT, CPVOLUME, etc.). Todo lo demás es simplemente formateo posterior y está más allá del alcance actual del artículo. Supongo que podríamos ampliar el alcance del artículo agregando una sección sobre "Formatización posterior" para agregar todo lo que queramos, pero hasta que haya una RS para un significado común diferente para el término y sus componentes, el artículo no debería cambiar el significado de los términos. 18:49, 23 de octubre de 2021 (UTC)

Notas

  1. ^ Anteriormente presenté al usuario: Tom94022 el caso de un zFS dentro de un conjunto de datos lineales (LDS) VSAM dentro de un volumen formateado z/OS.
  2. ^ Soy agnóstico en ese caso.
  3. ^ A partir de z/OS V2R5, el HFS que IBM introdujo en MVS/ESA SP V4R3 OpenEdition ya no recibe soporte y la instalación debe migrar cualquier HFS necesario a zFS.