Início / unix / Perguntas / 790680
Accepted
gcb
Asked: 2025-02-07 00:50:17 +0800 CST

Devo usar tamanho de setor físico ou lógico com LUKS?

  • 772

Tenho um HDD externo (não ssd) que informa:

Sector Sizes:     512 bytes logical, 4096 bytes physical

Devo usar --sector-size 512ou --sector-size 4096com cryptosetup LuksFormat? Usando parâmetros padrão (não tenho certeza se ele tenta detectar automaticamente ou usar 512 sempre) acabou com 512.

Se for importante, a configuração será[disk]->[gpt]->[physical partition]->[LUKSv2]->[btrfs]

Fui em frente e usei ambas as maneiras de coletar benchmarks:

512

# sysbench fileio prepare
2147483648 bytes written in 34.28 seconds (59.75 MiB/sec).

# sysbench fileio --file-test-mode=rndrw run
Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      14.42
    writes/s:                     9.62
    fsyncs/s:                     31.25

Throughput:
    read, MiB/s:                  0.23
    written, MiB/s:               0.15

General statistics:
    total time:                          12.4778s
    total number of events:              562

Latency (ms):
         min:                                    0.00
         avg:                                   17.84
         max:                                  365.73
         95th percentile:                       84.47
         sum:                                10024.98

Threads fairness:
    events (avg/stddev):           562.0000/0.00
    execution time (avg/stddev):   10.0250/0.00


# sysbench fileio --file-test-mode=seqrewr run
Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential rewrite test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      0.00
    writes/s:                     815.93
    fsyncs/s:                     1045.19

Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               12.75

General statistics:
    total time:                          10.0488s
    total number of events:              18576

Latency (ms):
         min:                                    0.00
         avg:                                    0.54
         max:                                  433.66
         95th percentile:                        0.02
         sum:                                 9996.57

Threads fairness:
    events (avg/stddev):           18576.0000/0.00
    execution time (avg/stddev):   9.9966/0.00

##4096

# sysbench fileio prepare
2147483648 bytes written in 28.85 seconds (70.99 MiB/sec).


# sysbench --test=fileio --file-test-mode=rndrw run
File operations:
    reads/s:                      26.17
    writes/s:                     17.45
    fsyncs/s:                     58.35

Throughput:
    read, MiB/s:                  0.41
    written, MiB/s:               0.27

General statistics:
    total time:                          11.4636s
    total number of events:              1041

Latency (ms):
         min:                                    0.00
         avg:                                    9.63
         max:                                  370.49
         95th percentile:                       44.98
         sum:                                10021.97

Threads fairness:
    events (avg/stddev):           1041.0000/0.00
    execution time (avg/stddev):   10.0220/0.00



# sysbench fileio --file-test-mode=seqrewr run
File operations:
    reads/s:                      0.00
    writes/s:                     1229.02
    fsyncs/s:                     1574.44

Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               19.20

General statistics:
    total time:                          10.0071s
    total number of events:              27929

Latency (ms):
         min:                                    0.00
         avg:                                    0.36
         max:                                  471.49
         95th percentile:                        0.02
         sum:                                 9997.75

Threads fairness:
    events (avg/stddev):           27929.0000/0.00
    execution time (avg/stddev):   9.9978/0.00

Para arquivos artificiais pequenos, 4K parece ser duas vezes mais rápido para leituras e 0,25 mais rápido para gravações.

Outra edição. Fiz o mesmo teste, mas copiando 110G de um pacote de arquivos variando de 2,5Mb (95%tile) a 300Mb.

Tanto a unidade formatada em 512 quanto a formatada em 4096 levou 20m30s +-4s

filesystems

1 respostas

  1. Best Answer

    Discos com setores de 4K, mas relatando setores lógicos de 512 bytes são conhecidos como unidades "Advanced Format" (AF). Eles emulam setores de 512 bytes. Mas eles fazem isso de uma forma ineficiente; por exemplo, para gravar um setor de 512 bytes, a unidade tem que ler os 4k de dados existentes, atualizar os dados necessários, gravar os resultados. Essa é uma etapa extra de "leitura", que não é necessária se estiver gravando setores de 4K.

    Você pode ver o resultado nos seus testes; os testes 4K são muito mais rápidos.

    Observe que isso também se aplica ao particionamento do disco; garanta que suas partições estejam alinhadas em 4K, caso contrário, cada gravação que o SO fizer poderá impactar 2 setores! Ferramentas como fdiskavisarão sobre esse desalinhamento.

    A única desvantagem de usar setores de 4K é que você pode acabar perdendo espaço útil; por exemplo, se você criar um arquivo de 300 bytes, isso ocupará 4K no disco, enquanto com setores de 512 bytes, ocuparia apenas 512 bytes. Considero isso uma troca justa pelas vantagens de velocidade.

    Então, no seu caso, eu usaria setores de 4K com cryptsetup.

    • 1

relate perguntas