[Digikam-users] backup and data integrity

[Gerhard Kulzer]

Am Wednesday 23 January 2008 schrieb Jakob Østergaard Hegelund:
> On Tuesday 22 January 2008, Arnd Baecker wrote:
> > On Mon, 21 Jan 2008, Gerhard Kulzer wrote:
> >
> > [...]
> >
> > > Arnd, can you send me the script? I'd like to try too.
> >
> > Done (off-list, it is really not ment for general consumption ... ;-)
> >
> > > I just read that strigi is exactly doing what we want, comparing
> > > files with sha1. Maybe sha1 is faster than md5?
> >
> > No idea. Maybe we should do a speed test at some point ;-)
>
> Both sha1 and md5 are designed to make it difficult to create a file
> with a specific checksum.  This is necessary for applications like
> digital signatures, but it usually comes at a significant performance
> (and complexity) premium.
>
> CRCs, on the other hand, were meant to catch what you're trying to
> catch, and will usually be a lot faster.
>
> A CRC64 should be more than sufficient to catch any of the mismatches
> you're looking for (CRC32, such as reported by the cksum command, would
> probably be good enough for most purposes as well). And it will
> definitely be much much faster than the cryptographically secure
> hashes.

Well seen Jakob :-)

I just came across an arcticle by Martin Petersen from Oracle 
(http://linux.sys-con.com/read/480659_1.htm, 3 pages).
They implement a end-to-end data protection mechanism using checksum metadata.
Citation:
"This CRC is quite expensive to calculate compared to other commonly used 
checksums. To alleviate the impact on system performance the TCP/IP checksum 
algorithm is used instead. This results in an almost negligible impact on 
system performance."

To me that sounds logical, I think we can stop searching here, it's just a 
matter of finding out how to best implement the TCP checksum.

Gerhard
-- 
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20080123/1a863d70/attachment.sig>