Dati corrotti

[The man with two watches]

Ciao a tutti

Ho preso spunto da questa notizia:
http://status.aws.amazon.com/s3-20080720.html
interpolata con la mia esperienza, per fare alcune considerazioni.

Anni fa avevo un file di backup di 1,5 GB del db da trasferire in
rete; il file originale era verificato come valido.
Faccio una copia su un drive di rete; la scrittura va a buon fine.
Apparentemente, almeno.
Al momento del ripristino il dbms si accorge che il file e` corrotto.

Eseguo una serie di test: 1 volta su 3 la copia fallisce
silenziosamente la scrittura del file da 1,5 GB. Con file di
dimensioni minori, andava tutto a buon fine. Probabilmente la bassa
frequenza del difetto era sufficiente da farla passare inosservata
nel caso di file piccoli, o di carico di lavoro basso. (*)

Le architetture dbms file-shared sono le piu` esposte a questo
pericolo; qual e` il problema? In epoca di computer da 200 euro,
che magari uno si porta dietro e attacca in LAN, gli
amministratori dovrebbero prestare attenzione a quanto segue:
essendo condiviso il file fisico del db, quando si scrive
un record, l'intera pagina da leggere viene trasferita in rete. Anche
se si modifica una solo valore, l'intera pagina viene rispedita
e sovrascritta per intero. La mancanza nel file del dbms di un CRC a
livello di pagina fa il resto.

Nel processo vengono coinvolti tutti i componenti hardware dei
computer, per cui la qualita` dell'intera catena di elaborazione
e` quella dell'anello piu` debole.

ciao

(*) nel caso siate curiosi, il pc era pure venduto a prezzi folli;
ho personalmente fatto il conto di quanto sarebbe
costato un pc uguale, assemblato con i medesimi componenti: ai
prezzi per privati, per quantita` singole, lo potevo assemblare
per circa la meta` del prezzo pagato (!).
I pc venivano forniti anche a grossi enti... quando ho fatto notare
al responsabile che i componenti erano sistematicamente i meno
costosi, la risposta e` stata tipo: "Ma che dice... sono gli stessi
pc che usano alla xyz"; he beh...

[Andrea [Work]]

Il Wed, 24 Sep 2008 20:07:56 GMT, The man with two watches ha scritto:

> Le architetture dbms file-shared sono le piu` esposte a questo
> pericolo; qual e` il problema? In epoca di computer da 200 euro,
> che magari uno si porta dietro e attacca in LAN, gli
> amministratori dovrebbero prestare attenzione a quanto segue:
> essendo condiviso il file fisico del db, quando si scrive
> un record, l'intera pagina da leggere viene trasferita in rete. Anche
> se si modifica una solo valore, l'intera pagina viene rispedita
> e sovrascritta per intero. La mancanza nel file del dbms di un CRC a
> livello di pagina fa il resto.
>
> Nel processo vengono coinvolti tutti i componenti hardware dei
> computer, per cui la qualita` dell'intera catena di elaborazione
> e` quella dell'anello piu` debole.

Ma il protocollo TCP/IP non dovrebbe avere un controllo al suo interno dei
singoli pacchetti trasferiti?

[The man with two watches]

"Andrea [Work]"

>> Nel processo vengono coinvolti tutti i componenti hardware dei
>> computer, per cui la qualita` dell'intera catena di elaborazione
>> e` quella dell'anello piu` debole.
>
> Ma il protocollo TCP/IP non dovrebbe avere un controllo al suo
> interno dei singoli pacchetti trasferiti?

Si, il pacchetto IP ha un CRC; alcune versioni (credo le piu` vecchie)
fanno il checksum dei soli dati, altri anche dell'header.
Pero` il meccanismo copre soltanto il trasferimento da scheda a scheda
di rete.

Se la RAM o il controller disco o altro sono fallati, i dati sono
corrotti "alla sorgente". C'e` pertanto la tendenza attuale a mettere
controlli tipo CRC in nuovi ambiti, tipo la cache della CPU o
i bus della scheda madre.

Eppure neanche cosi' bastera`: c'e` sempre un momento in cui i
dati vengono "disimpacchettati" per essere elaborati.

Taluni mainframe hanno tre processori, ciascuno dei quali computa
in parallelo la medesima istruzione; poi i risultati vengono
confrontati, e devono combaciare. Se fossero solo due processori, non
si saprebbe quale sia il risultato da scartare.
La probabilita` di errore in questo modo si riduce, ma non la si
elimina; si pensi ad esempio al caso del Pentium col famoso errore di
calcolo: in quel caso mettere tre processori in parallelo non avrebbe
fatto altro che produrre tre risultati sbagliati perfettamente uguali.

La morale e` che ottenere un'elaborazione libera da errori sembra
difficilissimo se non impossibile; alcune tecniche possono al piu`
ridurre le zone scoperte.

Tornando alla situazione di partenza, il calcolo che avevo fatto io
era il seguente:

1) Creo il backup del db --> il file e` su HD (CRC dei blocchi OK)
2) Lo verifico con l'utility specifica del dbms --> il file OK
3) Copio in rete (CRC del TCP/IP OK) --> trasferimento a buon fine
4) Scrittura sull'HD di destinazione (CRC dei blocchi OK)
5) Verifica con l'utility specifica del dbms: file corrotto

E' il punto 4 quello che mi faceva impazzire: CRC dell'HD a posto,
file diverso!
Forse qualcosa si risolverebbe usando solo i valori CRC originali
dell'HD senza ricalcolarli nel reimpacchettamento a dimensioni
differenti (inutile utopia, prima o poi ci sara` la necessita` di
variare la dimensione del pacchetto, o di fare letture parziali).

Da quella volta, per operazioni fondamentali, ho iniziato ad usare
programmi di hashing ed ECC. Anche per lavorare da casa ho scelto
uno XEON su piastra madre Intel, memorie certificate ECC; il bello
e` che non ho speso grandi cifre in piu` rispetto ad un
"corrispondente" (?) basato su Core...

[Andrea [Work]]

Il Thu, 25 Sep 2008 19:13:02 GMT, The man with two watches ha scritto:

> Da quella volta, per operazioni fondamentali, ho iniziato ad usare
> programmi di hashing ed ECC. Anche per lavorare da casa ho scelto
> uno XEON su piastra madre Intel, memorie certificate ECC; il bello
> e` che non ho speso grandi cifre in piu` rispetto ad un
> "corrispondente" (?) basato su Core...

Io penso dipenda anche da che tipo di sicurezza si vuol arrivare.
Personalmente ho trasferito archivi anche di grandi dimensioni, in archivi
zip o rar, magari con informazioni per il recupero.
E tali file sono stati trasferito via ftp/teleassistenza/email, e mai è
risultato corrotto.

Però ti parlo di piccole realtà, dove i clienti manco fanno i backup.
Mentre altri usano un DAT per 10 anni, salvo scoprire che poi han perso 2
mesi di lavoro, che sarebbero stati 12 se il sottoscritto non si fosse
preso un archivio di loro per fare delle prove...
E qui ti parlo di una ditta con 100 dipendenti.

La settimana dopo avevano un server con raid e triplo backup anche via
gigalan...