File speciale che causa errori I / O

Voglio testare automaticamente se un software reagisce come previsto se un file DB SQLite essenziale non viene letto (causando un errore I / O). È successo esattamente qualche giorno fa ad un cliente. L'abbiamo risolto manualmente, ma ora voglio creare un codice automatico per risolverlo e ho bisogno di accedere a un file danneggiato per verificarlo.

Dato che tutto in Unix è un file, sospettavo che potesse esserci un file speciale che causa sempre errori I / O quando si cerca di leggerlo (ad esempio in / dev).

Alcuni file simili (imo) sarebbero:

• /dev/full che dice sempre "Nessuno spazio lasciato sul dispositivo" se si tenta di scriverlo
• /dev/null e /dev/zero

quindi ho pensato che ci fosse un file come quello (ma non ne ho ancora trovato uno).

Qualcuno conosce un tale file o qualsiasi altro metodo per ottenere il risultato desiderato (un'immagine di partizione intenzionalmente difettosa, un wrapper attorno ad open () usando LD_PRELOAD, ...)?
Qual è il modo migliore per andare qui?

È possibile utilizzare dmsetupper creare un dispositivo Device Mapper utilizzando le destinazioni erroro flakeyper simulare errori.

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

Dove 123 è la lunghezza del dispositivo, in settori e / dev / loop0 è il dispositivo originale su cui si desidera simulare gli errori. Per errore, non sono necessari gli argomenti successivi poiché restituisce sempre un errore.

C'è già un grande insieme di risposte a Stack Overflow e Server Fault, ma mancavano alcune tecniche. Per semplificare la vita ecco un elenco di meccanismi di blocco degli errori di I / O della libreria di spazio VM / Linux / filesystem Linux / Linux userspace:

• Utilizzare i dispositivi error / flakey / delay / dm-dust di Device Mapper per restituire errori / corruzione o ritardare / dividere IO su un dispositivo a blocchi sintetizzato (kernel, richiede che il kernel sia stato costruito con il supporto di mappatore di dispositivi, moduli aggiuntivi di mappatore di dispositivi appropriati ( dm-dust è disponibile solo sul kernel> = 5.2) e per avere bit di spazio utente del mapper dispositivo).
• Usa la personalità difettosa di md per eseguire l'iniezione periodica di guasti su un dispositivo a blocchi sintetizzato. Vedi l' --layoutopzione della pagina man di mdadm per come configurarla (kernel e bit di spazio utenti mdadm).
• Usa libfiu per eseguire l'iniezione di errori sulle chiamate API POSIX (userspace, può essere usato con LD_PRELOAD).
• Utilizzare l' iniettore di errore del kernel Linux per iniettare un errore nel dispositivo a blocchi sottostante (il kernel richiede che sia stato compilato il kernel FAIL_MAKE_REQUEST=y).
• Usare SystemTap per eseguire l'iniezione degli errori (kernel, richiede che un kernel sia stato creato con molte cose ).
• Iniettare errori del filesystem usando CharybdeFS o PetardFS ( spazio utente tramite FUSE).
• Creare un dispositivo a blocchi sintetizzato usando il driver scsi_debug di Linux che esegue l'iniezione di errori (kernel).
• Esegui il tuo sistema in QEMU e usa QEMU per iniettare errori del dispositivo a blocchi usando il driver blkdebug (VM).
• Crea un dispositivo a blocchi sintetizzato tramite le opzioni del dispositivo null_blk per iniettare errori (kernel> = 4.14 ma opzioni come le probabilità di timeout non sono arrivate fino alla 4.17 e richiedono che il kernel sia stato costruito con BLK_DEV_NULL_BLK_FAULT_INJECTION=y).
• Creare un dispositivo di blocco di rete sintetizzato che viene servito all'host tramite filtri NBDkit come delayo errore quindi collegare un dispositivo di blocco tramite nbd-client(bit spazio utente + kernel NBD, kernel> = 4.18 costruito con supporto NBD, nbdclient> = 3.18 e nbdkit> = 1.8.1 consigliato - vedere il video dimostrativo NBDKit intorno al segno dei 20 minuti).

Informazioni aggiuntive: SQLite ha un driver VFS per la simulazione degli errori in modo da ottenere una buona copertura dei test.

Relazionato:

• Come posso simulare un disco guasto durante il test?
• Simulare un dispositivo a blocchi difettoso con errori di lettura?
• Genera un errore di lettura
• Causare intenzionalmente un errore I / O in Linux?

Volete un meccanismo di iniezione dei guasti per l'I / O.

Su Linux, ecco un metodo che non richiede alcuna configurazione precedente e genera un errore insolito (non EIO "Errore di input / output" ma ESRCH "Nessun processo di questo tipo"):

cat /proc/1234/mem

dove 1234 è il PID di un processo in esecuzione come lo stesso utente del processo che si sta testando, ma non quel processo stesso. Crediti per rubasov per pensare di /proc/$pid/mem.

Se si utilizza il PID del processo stesso, si ottiene EIO, ma solo se si sta leggendo da un'area che non è mappata nella memoria del processo. La prima pagina non viene mai mappata, quindi va bene se leggi il file in sequenza, ma non è adatto per un processo di database che cerca direttamente nel mezzo del file.

Con un po 'più di configurazione come root, è possibile sfruttare il mapper del dispositivo per creare file con settori validi e settori danneggiati.

Un altro approccio sarebbe quello di implementare un piccolo filesystem FUSE . EIO è il codice di errore predefinito quando il driver del filesystem dello spazio utente fa qualcosa di sbagliato, quindi è facile da ottenere. Entrambe le associazioni Perl e Python vengono fornite con esempi per iniziare, puoi scrivere rapidamente un filesystem che rispecchia principalmente i file esistenti ma inietta un EIO in luoghi scelti con cura. Esiste un tale filesystem: petardfs ( articolo ), non so quanto funzioni bene.

Ancora un altro metodo è un LD_PRELOADwrapper. Uno esistente è Libfiu (iniezione di errori nello spazio utente). Funziona precaricando una libreria che sovraccarica le chiamate API POSIX. È possibile scrivere semplici direttive o codice C arbitrario per sovrascrivere il comportamento normale.

La soluzione è molto più semplice se è corretto utilizzare un file dispositivo come "file con errori I / O". La mia proposta riguarda quei casi in cui un file normale deve contenere tali errori.

> 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 ammettere che sono un po 'confuso perché non sono riuscito a leggere singoli settori da quel file senza un errore (con dd .. seek=...). Forse questo è un problema di lettura anticipata.

È possibile utilizzare CharybdeFS creato esattamente per questo tipo di scopo.

È un filesystem con fusibili passthrough come PetardFS ma molto più configurabile.

Vedi il ricettario di CharybdeFS qui: http://www.scylladb.com/2016/05/02/fault-injection-filesystem-cookbook/

È abbastanza avanzato per testare un database.