From owner-freebsd-fs@FreeBSD.ORG Wed Jul 18 15:35:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44CB01065675 for ; Wed, 18 Jul 2012 15:35:32 +0000 (UTC) (envelope-from prvs=1546bf2d57=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C6F0E8FC0A for ; Wed, 18 Jul 2012 15:35:31 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Wed, 18 Jul 2012 16:34:34 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020834592.msg for ; Wed, 18 Jul 2012 16:34:34 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1546bf2d57=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: <8A24A3EFF4314670BAED740A02373F27@multiplay.co.uk> From: "Steven Hartland" To: "CH" , "Kai Gallasch" References: <20120717152629.42e0641e@fedora14-x86-64.shechinah.mi.microbiology.ubc.ca><6D778EEA-5B8F-4F59-B198-E5B098F3AE2C@free.de> <20120718075754.4908266b@kirk.lan> Date: Wed, 18 Jul 2012 16:34:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org Subject: Re: Can you list internal checksums of a ZFS filesystem? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:35:32 -0000 ----- Original Message ----- From: "CH" > Actually, I did do rsync for the initial transfers, and it had to be > restarted a couple of times for reasons that were not its fault (source > computer rebooted, ssh connection lost, etc). However, after it > finished copying everything (ie: exiting normally), I ran it again, and > it found more stuff to copy. This shouldn't have happened since > nothing was added to the source computer, and so now I distrust its > results and want to check it independently. In particular, I don't > trust its directory-walking algorithm, so some files may have been > missed and may continue to be missed in future runs of rsync, with or > without -c. > > The method I was going to use was 'find . -type f -print0 | xargs -0 > md5sum > my.big.md5sum.file' on both source and destination, but if I > can harvest the ZFS checksums (file or block) it would cut the cpu > workload in half, and save a tree's worth of energy. rsync is reliable when run on run cleanly. If like you had interruptions and you where running using say -av then it can miss changes if files changed but size or timestamps didn't. I've never had an run complete cleanly with a re-run detecting new files where files weren't in fact added. As mentioned --checksum (-c) forces checksums to be compared on both ends which will allow you to verify all is good. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.