Eu acho que esse é um comportamento correto. Os discos 4K ainda relatam setores de 512 bytes no lado da interface. Embora eles abordem internamente os setores em blocos de 4k.
O jumper está na maioria das unidades, permitindo apenas uma mudança de setor. Na maioria das unidades, ele altera o endereçamento do setor em 1. O motivo é o SO que não reconhece 4K, como o Winodws XP. Para entender, você precisa saber que o Windows XP cria a primeira partição para iniciar no setor 63 (sim, isso não é um erro de digitação).
Na maioria dos casos, o Windows usará um sistema de arquivos com 4k unidades de alocação (clusters NTFS). Portanto, você presumiria que, ao ler um cluster NTFS a partir de uma unidade tradicional, ele apenas lê 8 blocos físicos. Bem simples.
Agora, a unidade também usará o tamanho do setor em 4k. Isso é perfeitamente aceitável, pois o sistema operacional nunca lê clusters menores que 4k, já que esta é a menor unidade de alocação (supondo que você não forçou clusters FS menores durante o formato). Como escrevi, as unidades ainda expõem setores de 512 bytes no nível da interface por motivos de compatibilidade. Mas se você ler apenas um único bloco de 512 bytes, a unidade internamente lê um setor de 4k e o divide para enviar apenas 512 bytes pela interface do cabo.
Então, onde está o problema agora? ###
O problema com o Windows XP é que, como a partição está alinhada ao bloco 63 por padrão. Isso resulta em um desalinhamento de clusters NTSF para blocos físicos. Eu criei uma pequena imagem para ilustrar isso:
Como você pode ver na figura no Windows XP, o cluster lógico não está alinhado aos blocos físicos de 4k. Como resultado, se o Windows lê um cluster NTFS lógico, é necessário que a unidade leia dois blocos, e não apenas um. Pior ainda, se você apenas precisar de um único cluster NTFS, ele lê dois setores e precisa mesclá-los para retornar apenas os dados solicitados ao sistema operacional.
Para operações de gravação, é ainda pior. Nesse caso, a unidade precisa ler dois setores 4k físicos e mesclar seu conteúdo com o conteúdo do novo cluster NTFS antes de poder salvar novamente os dois setores no disco. Isso significa que, em vez de apenas substituir o setor no disco rígido, substituindo-o, a unidade precisa ler 8k, mesclar em um buffer e gravar 8k. Isso diminui bastante as operações de gravação.
Para evitar a fusão desnecessária, os fabricantes de HDD adicionaram um hack de "compatibilidade" que pode ser ativado via Jumper. Simplesmente incrementa cada endereço de setor de 512 bytes em 1. Como resultado, a primeira partição criada pelo Windows inicia no setor 64 e o mapeamento é o seguinte:
Agora, qualquer leitura / gravação de um bloco lógico de NTFS em 4k resulta na leitura / gravação exata de um setor físico.
Obviamente, essa solução alternativa não será necessária se você já criar suas partições alinhadas aos limites do setor de 4k. Por exemplo, no Linux, você pode simplesmente usar fdiskpara definir em qual bloco sua partição será iniciada. Portanto, é uma boa idéia usar uma multiplicação de 8 aqui.
O Windows está iniciando a primeira partição no setor 2048 AFAIR desde o Vista. Portanto, esse problema não ocorre mais aqui.
AVISO : Se você ainda usar a solução alternativa de jumper em sistemas operacionais prontos para 4k, como Vista, Win7 ou Win2k8 R2, isso poderá realmente quebrar o alinhamento do setor. O motivo é que a unidade aumentará novamente os endereços do setor em 1, resultando na primeira partição sendo alinhada ao setor 2049, o que novamente causa uma grande queda no desempenho.
Portanto, verifique se você está usando um sistema operacional com reconhecimento de 4K que remove o jumper antes de particionar a unidade. No seu caso específico, acho que tudo deve ficar bem, desde que você tenha repartido a unidade com o jumper removido. A formatação da unidade não tem nada a ver com alinhamento de setor e endereçamento 4K. A única coisa que você deve garantir durante o formato é que você não use tamanhos de cluster menores que 4k, pois os clusters NTFS de 2k resultariam no requisito de ainda ler um setor de 4k completo para cada acesso de disco rígido do sistema operacional. A propósito: O uso de clusters de 8k NTFS ainda é totalmente bom, pois o disco simplesmente lê 2 setores para cada operação de leitura / gravação NTFS.