Me gustaría mover una partición a una nueva unidad. La unidad antigua tiene un tamaño de sector de 512 bytes, mientras que la nueva tiene un tamaño de sector de 4096 bytes. Intenté agregar el disco completo, pero falló porque la partición del disco antiguo no estaba alineada con los límites de 4K. Entonces, en lugar de eso, creé una partición desde cero en la nueva unidad usando fdisk, luego copié esa partición entre discos usando dd. Finalmente, amplié el sistema de archivos en la nueva unidad usando resize2fs. Esto parece haber funcionado, ya que puedo montar la nueva partición (hasta ahora de solo lectura) y ver archivos, y fsck dice que está limpia.
Pero todavía tengo dudas sobre si esto es algo seguro. Por ejemplo, ¿el FS se preocupa por el tamaño del sector de una manera que rompería las cosas al hacer esto, o está protegido por la capa VFS o el propio HD?
Respuesta1
No nos ha dicho cuál fue el comando dd que intentó inicialmente y que falló. Sin embargo, dediqué un poco de tiempo a verificar el código fuente del comando dd (del paquete coreutils) y parece que tuvimos un problema aquí.
1852 /* Some devices require alignment on a sector or page boundary
1853 (e.g. character disk devices). Align the input buffer to a
1854 page boundary to cover all bases. Note that due to the swab
1855 algorithm, we must have at least one byte in the page before
1856 the input buffer; thus we allocate 2 pages of slop in the
1857 real buffer. 8k above the blocksize shouldn't bother anyone.
1858
1859 The page alignment is necessary on any Linux kernel that supports
1860 either the SGI raw I/O patch or Steven Tweedies raw I/O patch.
1861 It is necessary when accessing raw (i.e. character special) disk
1862 devices on Unixware or other SVR4-derived system. */
Si da el mensaje de error, puedo hacer una búsqueda adicional. Pero para mí, aquí es donde nos golpearon. Es decir, alinear el límite de la página de 512 bytes con un límite de página de 4 KiB no parece correcto.
Ahora, pasando a la segunda parte, ¿creó la partición de la segunda unidad (con fdisk) con un tamaño de 512 bytes? Sin embargo, el tamaño del sector anunciado por la mayoría de los discos modernos para el sistema operativo es 1 MiB, es decir, 4096 KiB.
En la función update_sector_offset de fdisk.c verás
/*
* Align the begin of partitions to:
*
* a) topology
* a2) alignment offset
* a1) or physical sector (minimal_io_size, aka "grain")
*
* b) or default to 1MiB (2048 sectrors, Windows Vista default)
*
* c) or for very small devices use 1 phy.sector
*/
sector_t x = 0;
if (fdisk_dev_has_topology(cxt)) {
if (cxt->alignment_offset)
x = cxt->alignment_offset;
else if (cxt->io_size > 2048 * 512)
x = cxt->io_size;
}
/* default to 1MiB */
if (!x)
x = 2048 * 512;
sector_offset = x / cxt->sector_size;
*cxt es el descriptor de la estructura fdisk.
Entonces esta parte no me queda clara. Es decir, si su nuevo disco anunciaba que el tamaño del sector era 4096 KiB o 512 bytes.
Ahora, llegando a la última parte.
No, a los sistemas de archivos en realidad no les importa el tamaño del sector. Y siempre que el tamaño del bloque sea de 4 KiB, todo debería estar bien, porque, dado que el tamaño de la página virtual (en contexto de mm) es de 4 KiB, la E/S mmaped debe alinearse con eso. En mi computadora portátil, el tamaño del bloque y el tamaño del sector físico son los mismos.
$ sudo blockdev --getpbsz /dev/sda
[sudo] password for chakraborty:
4096
$ sudo blockdev --getbsz /dev/sda
4096
IO ocurre en el contexto del tamaño del bloque, no del tamaño del sector. Si debido al tamaño del sector físico, FS encuentra algún problema, me sorprendería mucho. Sin embargo, VFS no llega tan lejos. VFS se encuentra entre la aplicación que emite IO y el sistema de archivos real. Lo que estamos discutiendo está debajo de la capa VFS.