Arquivo especial que causa erro de E / S

Desejo testar automaticamente se um software reage conforme o esperado, se um arquivo essencial do SQLite DB não for lido (causando um erro de E / S). Exatamente isso aconteceu alguns dias atrás em um cliente. Nós o corrigimos manualmente, mas agora quero criar um código automático para corrigi-lo e preciso acessar um arquivo quebrado para testá-lo.

Como tudo no Unix é um arquivo, suspeitei que possa haver um arquivo especial que sempre cause erros de E / S quando alguém tentar lê-lo (por exemplo, em / dev).

Alguns arquivos semelhantes (imo) seriam:

• /dev/full que sempre diz "Não resta espaço no dispositivo" se você tentar escrevê-lo
• /dev/null e /dev/zero

então eu assumi que só precisa haver um arquivo assim (mas ainda não o encontrei).

Alguém conhece um arquivo ou outro método para obter o resultado desejado (uma imagem de partição com defeito intencional, um invólucro em torno de open () usando LD_PRELOAD, ...)?
Qual é a melhor maneira de ir aqui?

Você pode usar dmsetuppara criar um dispositivo mapeador de dispositivos usando os destinos errorou flakeypara simular falhas.

dmsetup create test --table '0 123 flakey 1 0 /dev/loop0'

Onde 123 é o comprimento do dispositivo, em setores e / dev / loop0 é o dispositivo original no qual você deseja simular erros. Por erro, você não precisa dos argumentos subsequentes, pois sempre retorna um erro.

Já existe um ótimo conjunto de respostas para isso no Stack Overflow e Server Fault, mas algumas técnicas estavam faltando. Para facilitar a vida, aqui está uma lista dos mecanismos de injeção de falha de E / S do dispositivo de bloco VM / Linux / sistema de arquivos Linux / biblioteca de espaço de usuário Linux:

• Use os dispositivos error / flakey / delay / dm-dust do Mapeador de dispositivos para retornar erros / corrupção de ou retarde / divida a E / S para um dispositivo de bloco sintetizado (kernel, exige que o kernel tenha sido construído com suporte ao mapeador de dispositivos, módulos adicionais adequados para mapeamento de dispositivos ( O dm-dust está disponível apenas no kernel> = 5.2) e para ter bits de espaço no usuário do mapeador de dispositivos).
• Use a personalidade defeituosa do md para executar a injeção periódica de falhas em um dispositivo de bloco sintetizado. Veja a --layoutopção da página de manual do mdadm para saber como configurá-lo (bits do espaço de usuário do kernel e do mdadm).
• Use libfiu para executar a injeção de falhas nas chamadas da API POSIX (espaço do usuário, pode ser usado com LD_PRELOAD).
• Use o injetor de falhas do kernel do Linux para injetar um erro no dispositivo de bloco subjacente (o kernel, requer que o kernel tenha sido construído FAIL_MAKE_REQUEST=y).
• Usar o SystemTap para fazer a injeção de falhas (o kernel requer que um kernel tenha sido construído com muitas coisas ).
• Injete falhas no sistema de arquivos usando CharybdeFS ou PetardFS (espaço do usuário via FUSE).
• Crie um dispositivo de bloco sintetizado usando o driver scsi_debug do Linux que executa a injeção de falhas (kernel).
• Execute seu sistema no QEMU e use o QEMU para injetar erros de dispositivo de bloco usando o driver blkdebug (VM).
• Crie um dispositivo de bloco sintetizado através das opções do dispositivo null_blk para injetar falhas (kernel> = 4.14, mas opções como probabilidades de tempo limite não chegaram até 4.17 e exigem que o kernel tenha sido construído BLK_DEV_NULL_BLK_FAULT_INJECTION=y).
• Crie um dispositivo de bloco de rede sintetizado que seja servido ao host via filtros NBDkit como delayou errore, em seguida, conecte um dispositivo de bloco a ele via nbd-client(kernel + bits de espaço de usuário NBD, kernel> = 4.18 criado com suporte a NBD, nbdclient> = 3.18 e nbdkit> = 1.8.1 recomendado - veja o vídeo de demonstração do NBDKit em torno da marca de 20 minutos).

Fato bônus: o SQLite possui um driver VFS para simular erros, para obter uma boa cobertura de teste.

Palavras-chave:

• Como posso simular um disco com falha durante o teste?
• Simular um dispositivo de bloco defeituoso com erros de leitura?
• Gere um erro de leitura
• Intencionalmente causar um erro de E / S no Linux?

Você deseja um mecanismo de injeção de falha para E / S.

No Linux, aqui está um método que não requer nenhuma configuração anterior e gera um erro incomum (não EIO "Erro de entrada / saída", mas ESRCH "Não existe esse processo"):

cat /proc/1234/mem

onde 1234 é o PID de um processo em execução como o mesmo usuário que o processo que você está testando, mas não o processo em si. Créditos a rubasov por pensar em /proc/$pid/mem.

Se você usar o PID do próprio processo, obterá a EIO, mas apenas se estiver lendo de uma área que não está mapeada na memória do processo. A primeira página nunca é mapeada; portanto, tudo bem se você ler o arquivo sequencialmente, mas não for adequado para um processo de banco de dados que procura diretamente no meio do arquivo.

Com um pouco mais de configuração como raiz, você pode aproveitar o mapeador de dispositivos para criar arquivos com setores válidos e setores defeituosos.

Outra abordagem seria implementar um pequeno sistema de arquivos FUSE . EIO é o código de erro padrão quando o driver do sistema de arquivos do espaço do usuário faz algo errado, por isso é fácil de obter. As ligações Perl e Python vêm com exemplos para começar; você pode escrever rapidamente um sistema de arquivos que espelha principalmente os arquivos existentes, mas injeta uma EIO em locais cuidadosamente escolhidos. Existe um sistema de arquivos existente: petardfs ( artigo ), eu não sei o quão bem ele funciona imediatamente .

Ainda outro método é um LD_PRELOADinvólucro. Um existente é o Libfiu (injeção de falha no espaço do usuário). Ele funciona pré-carregando uma biblioteca que sobrecarrega as chamadas da API POSIX. Você pode escrever diretivas simples ou código C arbitrário para substituir o comportamento normal.

A solução é muito mais fácil se estiver OK usar um arquivo de dispositivo como "arquivo com erros de E / S". Minha proposta é para os casos em que um arquivo regular deve ter esses erros.

> dd if=/dev/zero of=/path/to/ext2.img bs=10M count=10
> losetup /dev/loop0 /path/to/ext2.img
> blockdev --getsz /dev/loop0
204800
> echo "0 204800 linear /dev/loop0 0" | dmsetup create sane_dev
> mke2fs /dev/mapper/sane_dev # ext2 reicht
> mount -t ext2 /dev/mapper/sane_dev /some/where
> dd if=/dev/zero of=/some/where/unreadable_file bs=512 count=4
> hdparm --fibmap /some/where/unreadable_file
/mnt/tmp/unreadable_file:
 filesystem blocksize 1024, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0       2050       2053          4
> umount /dev/mapper/sane_dev
> dmsetup remove sane_dev
> start_sector=$((204800-2053-1))
> echo $'0 2053 linear /dev/loop0 0\n2053 1 error\n2054 '"${start_sector} linear /dev/loop0 2054" | 
>   dmsetup create error_dev
> mount -t ext2 /dev/mapper/error_dev /some/where
> cat /some/where/unreadable_file # 3rd sector of file is unreadable
cat: /some/where/unreadable_file: Input/output error

Devo admitir que estou um pouco confuso porque não consegui ler setores únicos desse arquivo sem erro (com dd .. seek=...). Talvez esse seja um problema de leitura antecipada.

Você pode usar o CharybdeFS criado exatamente para esse tipo de objetivo.

É um sistema de arquivos de fusíveis de passagem como o PetardFS, mas muito mais configurável.

Consulte o livro de receitas do CharybdeFS aqui: http://www.scylladb.com/2016/05/02/fault-injection-filesystem-cookbook/

É avançado o suficiente para testar um banco de dados.