RESUMEN
Tengo una computadora portátil Dell Inspiron 17-5767 con un disco interno de 1 TB. He permitido que el Windows 10 enviado originalmente continúe teniendo y dominando por sí solo (es mi sistema operativo para juegos). Además, tengo dos unidades externas desde las cuales inicio y arrancaré mi sistema operativo Linux actual y futuro. Mi configuración actual es la siguiente:
- Puerto USB 3.0 n.º 0: Seagate Expansion+ 931,5 GiB (1000204885504 bytes) Disco duro externo reconocido como /dev/sdb
- Actualmente alberga una partición ext4 vacía de tamaño completo, pero ha estado luchando por reemplazarla con un esquema de partición alineado óptimo de 12 particiones (el punto de dificultad es la alineación)
- Puerto USB 3.0 n.º 1: 238,5 GiB (256060514304 bytes) Samsung SSD 840 Pro reconocido como /dev/sdc
- fue particionado usando el instalador de Fedora LiveCD (con la opción "personalizado") y alberga mis distribuciones de Linux Fedora LXDE y Lubuntu dentro de un único LVM que contiene un espacio de intercambio compartido, espacio de usuario compartido, raíces separadas y particiones de arranque externas separadas (por externo aquí, solo me refiero no en el LVM sino en sus propias particiones primarias separadas en otras partes del mismo disco)
- Esta unidad tiene un tamaño de bloque físico y lógico de 512 y está alineada de manera óptima, según la utilidad 'align-check opt x' de parted, y fdisk también está contento con la alineación (no hay quejas de alineación por parte de ninguna utilidad)
- UEFI BIOS intenta arrancar desde USB antes que interno, por lo que aparece grub con todas mis opciones disponibles
META
Estoy intentando replicar algo parecido a lo que estoy pasando con /dev/sdc en la unidad /dev/sdb, pero con 5 distribuciones de Linux. Ese aspecto de mi proyecto lo he cubierto, ya que soy un iniciador múltiple experimentado. Pero la otra parte de mi objetivo es que mi partición en /dev/sdb esté alineada de manera óptima tal como es el caso con /dev/sdc, y aquí es donde tengo problemas.
AMBIENTE
Actualmente estoy trabajando desde mi instalación relativamente nueva y actualizada de Fedora LXDE, y los resultados que obtengo son totalmente repetibles también en mi instalación relativamente nueva y actualizada de Lubuntu.
PARÁMETROS DE DISCO INFORMADOS
[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C
Device Start End Sectors Size Type
/dev/sdb1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[root@frank ~]#
PROBLEMA
Entonces, según el informe del tamaño del bloque físico, parece que el disco es 4k (formato avanzado) en lugar de 512b como la otra unidad, aunque por motivos de compatibilidad con versiones anteriores utiliza un tamaño de sector lógico de 512b. Puedo decir que la utilidad separada GNU asume un tamaño de bloque de 512, porque cuando calcula el intervalo IO óptimo
(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval
obtiene un valor de 65535, que es donde iniciará automáticamente la primera partición, y la única forma en que la subutilidad align-check pasará una alineación de partición como óptima es si comienza en un múltiplo de 65535. La única forma de separarse El resultado tiene sentido si considera que está tratando el tamaño_físico como 512 en lugar de 4096.
(33553920 + 0) / 512 = 65535.
Sin embargo, es comprensible que parted no pueda usar el tamaño de bloque 4096, porque entonces la ecuación resultaría
(33553920 + 0) / 4096 = 8191.875.
Esa respuesta satisfaría a un profesor de álgebra de secundaria, pero obviamente no tiene sentido como intervalo de sector para el cual se esperaría un valor discreto (es decir, ¡un número entero!). En cualquier caso, como quiero crear 12 particiones, algunas de las cuales tienen un tamaño tan pequeño como 256 MiB, eso no es posible hacerlo en GNU Parted usando porcentajes y, en pocas palabras, solo pude satisfacer las comprobaciones de alineación para una alineación óptima. Seguir con las 'unidades s' y hacer la aritmética modular yo mismo para asegurarme de que mis particiones comenzaran en intervalos de 65535 s, de la forma en que la separación quería que lo hiciera. Según mi investigación, no pensé que fuera tan importante asegurar que mis particiones también terminaran en esos intervalos y, por lo tanto, me quedaron espacios (obviamente no mayores a 65535) entre la mayoría de mis particiones.
Una vez más, parted pensó que mi resultado estaba alineado de manera óptima, tratando el tamaño del bloque físico como 512 en lugar de 4096. Pero luego, después de salir de parted y ejecutar 'fdisk -l /dev/sdb', el resultado contenía lo siguiente:
Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.
Entonces, lo que le gusta a partid, a fdisk no. Entonces intenté usar gParted para rehacer mi esquema de partición, permitiéndole usar 1 MiB como tamaño de unidad, e inició la primera partición en 2048, como vería en mi otro disco (/dev/sdc). Entonces fdisk se alegró y dejó de quejarse de la alineación del sector, pero luego GNU parted falló las pruebas de verificación de alineación para el modo óptimo, aunque pasaría por el modo mínimo.
Sin embargo, encontré que en ambos casos, mkswap (que usé para crear un volumen de intercambio dentro del LVM que coloqué en /dev/sdb11) me dio la siguiente advertencia:
[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned
Entonces, mkswap encuentra que mi volumen de intercambio está desalineado, ya sea que parted piense que el disco está alineado de manera óptima o mínima, y mkswap también encuentra que mi volumen de intercambio está desalineado, ya sea que fdisk esté satisfecho con la alineación o no.
TEORÍAS
Todo esto me deja con la impresión de que tendré que ignorar las advertencias de al menos una utilidad de partición o de informes de disco, pero no estoy seguro de cuál. También es posible que, para empezar, todos los informes no sean confiables, ya que la carcasa compatible con USB que contiene el disco duro podría estar informando erróneamente al menos uno de los parámetros del sector. Por ejemplo, ¿tal vez no sea en realidad una unidad AF? O tal vez se esté informando erróneamente el tamaño óptimo de IO. ¿O tal vez ambos? Y, créame, también he considerado la posibilidad de que este sea un caso PEBKAC, ya que podría estar entendiendo mal algo sobre cómo alinear particiones en una unidad de 4k. No estoy seguro.
Pase lo que pase, estaré feliz de seguir adelante con mis instalaciones reales de Linux una vez que crea que mis particiones están alineadas de manera óptima y mkswap, o al menos las utilidades en las que realmente debería confiar más, dejen de quejarme sobre la alineación.
AYUDA
Ayúdenme a comprender por qué parece que no puedo separarme y otras utilidades de disco para acordar algo más que la alineación mínima (que se logra solo al particionar con gParted o gdisk), y avísenme si realmente debería preocuparme demasiado. sobre las ventajas de la alineación óptima sobre la alineación mínima en mi caso, ya que no perderé más tiempo si hay una diferencia demasiado insignificante en el rendimiento o el estado del disco. De lo contrario, me gustaría poder aprovechar al máximo los beneficios del formato avanzado de mi disco.
Respuesta1
En caso de que todavía estés confundido por el extraño número 65535. También estoy confundido por esta pregunta recientemente. Busqué una respuesta y encontré esta:http://gparted-forum.surf4.info/viewtopic.php?id=17839
Brevemente, el Optimal_io_size podría no ser válido cuando el disco duro está conectado a una PC con un adaptador USB-SATA.
La solución es simplemente ignorar este número y ceñirse a la sugerencia del límite de 1MiB.