Gostaria de mover uma partição para uma nova unidade. A unidade antiga tem um tamanho de setor de 512 bytes, enquanto a nova tem um tamanho de setor de 4.096 bytes. Tentei fazer um dd do disco completo, mas falhou porque a partição da unidade antiga não estava alinhada aos limites de 4K. Então, em vez disso, criei uma partição do zero na nova unidade usando fdisk e copiei essa partição entre os discos usando dd. Finalmente, expandi o sistema de arquivos na nova unidade usando resize2fs. Parece que isso funcionou, pois posso montar a nova partição (somente leitura até agora) e visualizar os arquivos, e o fsck diz que está limpo.
Mas ainda tenho dúvidas sobre se isso é seguro. Por exemplo, o FS se preocupa com o tamanho do setor de uma forma que quebraria as coisas ao fazer isso, ou é protegido disso pela camada VFS ou pelo próprio HD?
Responder1
Você não nos disse qual foi o comando dd que você tentou inicialmente e falhou. No entanto, passei um pouco de tempo verificando o código-fonte do comando dd (do pacote coreutils) e parece que tivemos um problema aqui.
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. */
Se você der a mensagem de erro, posso fazer uma pesquisa adicional. Mas para mim, foi aqui que fomos atingidos. Isso é alinhar o limite da página de 512 bytes com um limite da página de 4 KiB não parece certo.
Agora, chegando à segunda parte, você criou a partição do segundo drive (com fdisk) com tamanho de 512 bytes. No entanto, o tamanho do setor anunciado pela maioria dos discos modernos para o sistema operacional é de 1 MiB, ou seja, 4.096 KiB.
Na função update_sector_offset de fdisk.c você verá
/*
* 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 é o descritor da estrutura fdisk.
Então, essa parte não está clara para mim. Isto é, se o seu novo disco anunciasse o tamanho do setor como 4.096 KiB ou 512 bytes.
Agora, chegando à última parte.
Não, os sistemas de arquivos não se importam com o tamanho do setor. E contanto que o tamanho do bloco seja de 4 KiB, tudo deve ficar bem, porque, como o tamanho da página virtual (no contexto mm) é de 4 KiB, o IO mapeado precisa estar alinhado com isso. No meu laptop, o tamanho do bloco e o tamanho do setor físico são iguais.
$ sudo blockdev --getpbsz /dev/sda
[sudo] password for chakraborty:
4096
$ sudo blockdev --getbsz /dev/sda
4096
IO acontece no contexto do tamanho do bloco, não no tamanho do setor. Se devido ao tamanho do setor físico o FS encontrar algum problema, ficaria muito surpreso. No entanto, o VFS não vai tão longe. O VFS está entre a emissão do aplicativo IO e o sistema de arquivos real. O que estamos discutindo está abaixo da camada VFS.