quixotrykd's questions

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!

Ouvi dizer que o RAID 1+0 é mais dependente de falhas do que o RAID 0+1, porque é mais provável que uma falha na unidade secundária cause perda de dados no RAID 0+1 do que no RAID 1+0.

Na imagem acima, se o “Disco 1” falhar, quais outras falhas de disco causarão perda de dados? O que li parece indicar que a perda de qualquer unidade no "Grupo 2" causará perda de dados, mas o raciocínio por trás disso não está claro para mim. Se perdermos o “Disco 5”, por que isso causaria perda de dados? Parece-me que há informações suficientes para recuperar o estado completo dos dados - combinar "Disco 4" + "Disco 2" + "Disco 3", por exemplo, deve ter todas as informações necessárias para continuar funcionando corretamente sem dados perda.

Nesse caso, por que a perda do “Disco 1” e do “Disco 5” causaria perda de dados?

Desde já, obrigado!

Muitas vezes, especialmente ao mexer com carregadores de inicialização, vejo números numéricos de unidade e partição usados. Por exemplo, no meu /boot/grub/grub.cfgI see set root='hd0,gpt2', minhas entradas de inicialização UEFI geralmente fazem referência a números de unidade/partição e parece surgir em quase qualquer contexto em que os carregadores de inicialização estejam envolvidos.

Agora que temos UUID e PARTUUID, endereçar partições dessa maneira parece incrivelmente instável (afaik, não é garantido que as unidades sejam montadas sempre na mesma ordem, um usuário pode mover a ordem das unidades conectadas em sua mobo, etc.)

Minhas perguntas, portanto, são duas:

1. Esse esquema de endereçamento é tão instável quanto descrevi acima? Estou faltando algo no padrão que significa que esse esquema é muito mais confiável do que eu esperava, ou esse esquema de endereçamento realmente tornará seu sistema não inicializável (até que você corrija suas entradas de inicialização pelo menos) como resultado de suas unidades simplesmente serem reconhecidas em um ordem diferente ou conectá-los em slots diferentes na sua placa-mãe?

2. Se a resposta para a pergunta acima for sim, então por que esse esquema de endereçamento continua a ser usado? Usar UUID ou PARTUUID para tudo não seria muito mais estável e consistente?

Pelo que entendi, o bootloader GRUB em um sistema BIOS (e a maioria dos outros bootloaders) são compostos de 3 partes. A primeira parte (estágio 1) é armazenada nos primeiros 448bytes, que é responsável por passar o controle para o chamado estágio 1.5, localizado um pouco mais adiante na memória. Este estágio finalmente carrega o estágio 2 da pasta /boot e transfere o controle para ele.

Como o estágio 1 sabe em qual estágio de disco 1.5 reside? Uma vez que o código no estágio 1 começa a ser executado, não há como ele saber de qual disco foi carregado (a menos que essa informação seja de alguma forma passada para o estágio 1 ou o próprio BIOS também carregue o estágio 1.5 na memória?)

Do estágio 1.5 ao estágio 2, novamente, como o estágio 1.5 sabe em qual disco (e em qual partição) o diretório /boot reside?

Eu executo o comando (Xorg & sleep 3; xeyes) &para testar o Xorg e o agrupo em um único trabalho em segundo plano de subshell para facilitar o gerenciamento. Isso funciona corretamente e abre xeyes na nova sessão do Xorg após 3 segundos.

Ao executar o comando, obterei uma saída como a seguinte:

[1] 635

Depois de executar ps -efpara verificar novos processos, obterei uma saída como a seguinte:

root    635    361    0    4:52    tty1    00:00:00    -bash
root    636    365    0    4:52    tty2    00:00:00    /usr/lib/Xorg
root    639    365    0    4:52    tty1    00:00:00    xeyes

Esta parece ser uma saída bastante padrão e como esperado. Depois de verificar que meu servidor X funciona conforme o esperado, tento matar este grupo com kill %1. Ao executar isso, meus processos agora ficam assim:

root    636    1    0    4:52    tty2    00:00:00    /usr/lib/Xorg

Por que o Xorg não conseguiu sair? Por que o subshell saiu com sucesso, fechando o xeyes corretamente, mas não trouxe o Xorg junto com ele? Por que o processo pai do Xorg agora mudou para 1 em vez do subshell? O subshell não deveria enviar um sinal de kill para todos os seus processos filhos ao sair?

Além disso, se eu matar o grupo com kill 635, que muitos recursos dizem que deve ser equivalente a kill %1, meu estado de processo é ainda mais bizarro:

root    636    1    0    4:52    tty2    00:00:00    /usr/lib/Xorg
root    639    1    0    4:52    tty1    00:00:00    xeyes

O que??? Por que ambos os processos falharam ao sair agora e agora são filhos do PID 1? O que está acontecendo aqui, e o que estou fazendo de errado?

Uma explicação detalhada do que exatamente está acontecendo aqui seria apreciada, além de apenas me dizer o que fazer.