Gestione di potenziali errori durante l'aggiunta di dati a un file su disco

Naviga le tue risposte
4

Sto progettando un'applicazione che aggiungerà blob a un file su disco (file system locale) e attualmente sto pensando a come gestire i problemi di coerenza che potrebbero verificarsi se:

  • L'applicazione si blocca improvvisamente
  • L'intero sistema si arresta, ad es. a causa di un'interruzione di corrente

L'obiettivo è che, quando il file viene letto più tardi, l'applicazione che processa i BLOB dovrebbe essere in grado di distinguere se un blob è stato danneggiato (e quindi evitare di elaborarlo).

La mia idea attuale è quella di scrivere quanto segue su disco per ogni blob e flush dopo ogni:

[Size of blob] (4 byte) [CRC-32 hash of blob] (4 byte, altro per rilevare i problemi mentre i file invecchiano nel tempo) [actual blob bytes]

Ecco le domande:

  • Questo garantisce che, nel caso si verificasse una qualsiasi delle condizioni sopra descritte, il file conterrà solo dati validi, o n blob validi + alcuni byte extra dove interpretare i primi quattro come dimensione indicherà facilmente che non ci sono abbastanza rimanenti byte nel file per un blob appropriato (oppure i byte extra sono sotto i 4, non abbastanza per contenere le dimensioni corrette)?
  • Potrebbero essere presenti byte corrotti che sono stati precedentemente scritti sul disco all'interno del file?
  • Potrebbe una perdita di potenza corrompere il file in modo tale da apparire più grande di quanto dovrebbe (e quindi contenere vari rifiuti alla fine)?
  • I vari filesystem possono portare a comportamenti strani a questo riguardo? L'applicazione sarà multipiattaforma e sto cercando di evitare di scrivere codice specifico per piattaforma per questo.

Alcune altre considerazioni:

  • I blob saranno relativamente piccoli (intorno a qualche kB, < 100 kB)
  • La perdita di un numero di blob in caso di arresto improvviso è accettabile
  • Quando l'applicazione viene riavviata, creerà un nuovo file vuoto, non accodato a uno già esistente
  • Solo un thread di un processo eseguirà l'aggiunta
  • Non è consentito leggere il file prima che sia chiuso
  • Se si verifica un'interruzione dell'alimentazione, dopo il riavvio verrà eseguito un controllo di coerenza sul file system.
posta D. Jurcau 14.04.2017 - 12:18
fonte

2 risposte

1

Sfortunatamente, il tuo schema semplice non ti protegge dagli errori del disco o dalla corruzione dei dati.

Il punto debole è nella dimensione non protetta, che è necessario leggere in sequenza il file e trovare il successivo blob. Quindi in caso di errore di scrittura, sulla dimensione si può perdere tutto dalla prima brutta dimensione alla fine del file. Questo può accadere in due varianti:

  • creazione di un nuovo oggetto: si scrivono i dati correttamente (ad esempio un blob di m byte) e quindi si scrivono diversi altri blob. Immagina che il sistema operativo scriva le dimensioni sul disco con una corruzione non rilevata. Quando in seguito leggerai di nuovo il file, scoprirai la taglia sbagliata n. C'è un'alta probabilità che il CRC evidenzi l'incoerenza, ma lo farà sui n byte che seguono (sebbene il blob fosse completamente corretto). Peggio ancora, i n byte saranno scartati come blob difettoso, e da quel momento in poi il tuo codice cercherà di leggere il blob successivo in un posto sbagliato (offset + n invece di offset + m).
  • manutenzione dei file all'esterno dell'applicazione: ad esempio, il file blob viene copiato da un server a uno più performante. Se durante il trasferimento un carico di blob è danneggiato, solo questo blob andrà perso. Tuttavia, se durante la copia le informazioni sulla dimensione vengono danneggiate, perdi tutti i successivi blob.

In modo simile, gli errori potrebbero anche influenzare i dati già scritti. Ad esempio su un SSD, un errore hardware potrebbe portare un po 'a capovolgere, un difetto hardware potrebbe anche influenzare la memoria cache del disco (ad esempio riga martello effetti simili). Alcuni filesystem (o anche l'hardware ) provano a riscrivere un unità di allocazione, se sembra che si trovi in un settore di hard disk difettoso), ecc ... Ma questi sono problemi che riguardano la maggior parte delle strutture di dati, non solo le tue. Un modo per ridurli è leggere i dati che hai scritto per verificarne la coerenza.

    
risposta data 14.04.2017 - 15:09
fonte
0

Hrm .... Potresti semplicemente scrivere i tuoi blob in un file temporaneo, quindi cambiare il nome del file quando è pronto? Ciò limiterà notevolmente i tuoi errori durante la scrittura e potrai facilmente vedere quali file non hanno apportato la modifica.

    
risposta data 14.04.2017 - 13:56
fonte

Leggi altre domande sui tag

Comunicazione tra direttive angolari e controllore genitore Costruire oggetti da più query del server asincrono