Início / unix / Perguntas / 779694
Accepted
quixotrykd
Asked: 2024-07-08 08:49:59 +0800 CST

O RAID sempre lê/grava um pedaço inteiro?

  • 772

Muitos recursos na Internet contêm informações conflitantes sobre a lógica de leitura/gravação de blocos RAID.

Esta resposta contém as seguintes informações (aparentemente conflitantes):

Um tamanho de bloco de 512 KB não exige que o sistema grave, por exemplo, 512 KB para cada gravação de 4 KB ou leia 512 KB da superfície do dispositivo para uma leitura de aplicativo de 4 KB.

[Ao ler um bloco de 16 KiB do RAID com um tamanho de bloco de 64 KiB] o RAID executará uma operação de leitura/modificação/gravação ao gravar esse arquivo de 4 KiB/bloco de 16 KiB porque a menor unidade de armazenamento do RAID é 64 -KiB.

Por outro lado, este recurso contém as seguintes informações:

Por exemplo, se você tiver um arquivo de texto de 10 KB e o tamanho do bloco for 256 KB, esses 10 KB de dados serão armazenados em um bloco de 256 KB, deixando o restante do bloco vazio. Por outro lado, com blocos de 16 KB, há muito menos desperdício de espaço ao armazenar esse arquivo de 10 KB.

Em particular, tenho as seguintes perguntas:

  1. Ao ler/gravar alguma unidade de dados menor que o tamanho do bloco RAID usando um esquema sem paridade, isso requer uma operação de leitura/modificação/gravação para todo o bloco ou apenas a parte do bloco que é modificada?
  2. Ao usar um esquema RAID com paridade, isso muda alguma coisa na resposta à pergunta 1?
  3. Conforme mencionado na segunda referência, escrever uma unidade de dados menor que o bloco RAID de alguma forma deixa o restante do bloco RAID vazio? Isso me parece incorreto, mas gostaria de esclarecer, pois este recurso afirma isso de forma bastante inequívoca.
  4. Alguma dessas respostas muda dependendo da implementação do RAID (kernel Linux, RAID de hardware, etc.)?

Se possível, fornecer algum tipo de referência oficial (alguma especificação de RAID, código-fonte, etc.) seria incrível.

Desde já, obrigado!

raid

1 respostas

  1. Best Answer

    O tamanho do bloco determina principalmente como os dados são distribuídos entre os dispositivos (qual dispositivo físico e deslocamento procurar se você quiser ler o byte 1234567890 no seu dispositivo RAID).

    Não afeta diretamente o algoritmo RAID, que no caso do RAID 5 é uma operação XOR simples, também conhecida como XOR bit a bit . Matematicamente, isso opera em bits e, como tal, não depende de bytes, setores ou pedaços. O RAID 6 é um pouco mais complexo, mas ainda assim bastante semelhante.

    Como tal, não há necessidade de processar todo o pedaço.

    Para Linux mdadm RAID, você pode tentar verificá-lo experimentalmente:

    Crie algumas unidades virtuais (usando arquivos esparsos):

    # truncate -s 1G {1..8}.img
# for img in {1..8}.img; do losetup --find --show "$img"; done
/dev/loop{1..8}

    Coloque um mdadm RAID 6 em cima (usando --assume-cleanpara que não grave nada, além de metadados):

    # mdadm --create --assume-clean --level=6 --raid-devices=8 --data-offset=2048 /dev/md42 /dev/loop{1..8}
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md42 started.

    Gravação pequena em um deslocamento aleatório:

    # blockdev --getsize64 /dev/md42
6429868032
# echo $((SRANDOM % 6429868032))
2931013558
# echo -n TEST | dd bs=1 seek=2931013558 of=/dev/md42
# sync
# echo 3 > /proc/sys/vm/drop_caches

    Resultado:

    # filefrag {1..8}.img
1.img: 1 extent found
2.img: 1 extent found
3.img: 2 extents found
4.img: 1 extent found
5.img: 2 extents found
6.img: 2 extents found
7.img: 1 extent found
8.img: 1 extent found

    Todas as imagens têm 1 extensão (para metadados mdadm), então você pode ignorá-la. Apenas 3 imagens possuem 2 extensões (dados, paridade 1, paridade 2). Portanto, apenas estes foram escritos.

    # filefrag -v -e 3.img 5.img 6.img
File size of 3.img is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        1..       1:     301057..    301057:      1:          1: merged
   1:   119739..  119739:     318395..    318395:      1:     420795: last,merged
3.img: 2 extents found

    Como você pode ver, a extensão é um único setor, não um pedaço.

    Os dados brutos são assim:

    # hexdump -C 3.img
*
1d3bb7b0  00 00 00 00 00 00 54 45  53 54 00 00 00 00 00 00  |......TEST......|
1d3bb7c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
# hexdump -C 5.img
*
1d3bb7b0  00 00 00 00 00 00 54 45  53 54 00 00 00 00 00 00  |......TEST......|
1d3bb7c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
# hexdump -C 6.img
*
1d3bb7b0  00 00 00 00 00 00 29 24  59 29 00 00 00 00 00 00  |......)$Y)......|
1d3bb7c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

    Como todos os dados são zero, a paridade do RAID 5 TESTainda é TEST. Para paridade RAID6, TESTtransformado em )$Y).

    Você pode estender esse experimento preenchendo a matriz com dados aleatórios e, em seguida, escrever apenas {4,16,512,4096,16384} bytes de zero no deslocamento desejado para apenas um ou vários desses 3 dispositivos e, em seguida, repetir o experimento.

    Dessa forma, você pode determinar que o mdadm não está operando em resolução de nível de byte único (mas ainda não indo além dos setores, sem mencionar pedaços inteiros).

    Você também pode notar que ele grava a paridade errada se a paridade já estiver errada antes da gravação (paridade atualizada usando paridade em vez de recalcular a partir dos dados).

    • 3

relate perguntas