ext4 file checksum

Ciao,

mi sembra che in ext4 i file siano sottoposti a checksum per verificarne
l'integrità.Volevo sapere se si, come è
possibile leggere questo valore di checksum per implementare poi un
furbo algoritmo di copia solo dei file
modificati ...

attachment.htm (2.02 KB)

Ciao,

Ciao,

mi sembra che in ext4 i file siano sottoposti a checksum per verificarne
l'integrità.Volevo sapere se si, come è

Uhm così sui due piedi mi viene da dire "non lo so". Il più diffuso
programma per calcolare un checksum è IMHO md5sum.

possibile leggere questo valore di checksum per implementare poi un
furbo algoritmo di copia solo dei file
modificati ...

...cos'ha rsync che non va? :wink:

rsync fa esattamente quanto chiedi: spezza un file in chunks, ne
calcola i checksums e copia/trasferisce solo i chunks modificati:
https://rsync.samba.org/tech_report/tech_report.html

HTH,
Stefano

ext4 no, forse ti confondi con btrfs.
ext4 ha solo il checksum per il journal.

In entrambi i casi pero, il block checksum e' un semplice CRC32
(crc32e?), sufficiente per qualche corruzzione casuale, ma non per
validare il contenuto IMHO.

per copiare i file modificati hai a disposizione il timestamp.
Vedi rsync, oppure anche "find -newer".

Ciao ragazzi,

certo rsync e` uno strumento potentissimo e lo uso spessissimo.
Il problema che ho riguarda alcuni progetti eclipse. Sembra che
alcuni file di configurazione di progetto non risultano modificati
nella data e dimensione ma nel
contenuto si, rsync non li nota.

Mettendo il parametro -c a rsync gli chiedo di fare un checksum per capire
se anche il contenuto e` diverso. Cosi si accorge di questi file.

Solo che usando il parametro -c diventa tutto molto peggio, in quanto rsync
deve fare un checksum di tutti i file, anche quelli non potenzialmente cambiati,
che come tempo in pratica e` come ricopiare tutto da capo ! Infatti si
deve rileggere tutto!
Leggendo solo data e dimensione invece trova i file cambiati molto
molto piu velocemente!

in btrfs invece e` possibile avere un checksum del file?

Concordo con il fatto che un semplice CRC32 possa essere fragile
nel determinare contenuti diversi. Non penso tanto alle collisioni,
ma quanto al fatto che essendo una semplice somma, basta per esempio
spostare un testo all'interno di un file e per lui il crc e` uguale !

Grazie, ciao!

Davide, questa mi piace assai. Seguo il track che apri.
diego

attachment.htm (3.36 KB)

uhm... e tu come te ne accorgi? Cioè, devi/dovresti aprire ogni file
per verificare che è cambiato o basta uno stat?

In questo caso, comunque credo che usare MD5 (o analoga funziona di
hash tipo sha256) sia l'unico modo per vedere la differenza ed è
appunto quello che fa rsync -c (man rsync per i dettagli).

Così sui due piedi non so se esista qualcosa che tenga conto anche di
queste modifiche (ma non riesco a trovare un caso di come faccia un
file, il cui contenuto viene cambiato, a non vedere modificato il
ctime. Forse rdiff-backup (untested) puo' fare qualcosa in questo
senso.

Per velocizzare il processo, rimanendo su rsync, forse un approccio di
questo tipo (eventualmente scriptabile) ti salva un po' di tempo:

1) crea un file con i md5 di tutti i files (sums.txt)
2) fai un rsync (così intanto "sposti" i file effettivamente cambiati)
3) rifai un md5 (sums-new.txt)
4) fai un ~# diff sums.txt sums-new.txt (scopri i file "modificati" ma
sfuggiti al primo giro di rsync)
5) dai in pasto a rsync -c la lista dei file differenti.
6) sostituisci sums-new.txt a sums.txt

Al momento non mi viene niente di meglio :slight_smile:

HTH,
Stefano

Ciao,

rsync infatti, vuole ottimizzare la trasmissione dei file, e` un po`
un'altra cosa....

butto un altra cosa nella mischia: inotify! Con quell'api ti puoi fare
eseguire dei trigger quando cambia qualcosa sul file system....
Potrebbe solvere il caso tuo...

Bye, Chris.