From owner-freebsd-questions@FreeBSD.ORG Tue Nov 1 21:38:46 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E57216A41F for ; Tue, 1 Nov 2005 21:38:46 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14A3F43D45 for ; Tue, 1 Nov 2005 21:38:44 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 3BAB65E36; Tue, 1 Nov 2005 16:38:44 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73665-04; Tue, 1 Nov 2005 16:38:41 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 9C3F55C49; Tue, 1 Nov 2005 16:38:41 -0500 (EST) Message-ID: <4367E067.5060405@mac.com> Date: Tue, 01 Nov 2005 16:38:47 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-questions@freebsd.org Subject: Re: two quick conceptual questions RE: rsync (and rsyncing snapshots) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 21:38:46 -0000 user wrote: > Chuck - thank you... Sure. > On Tue, 1 Nov 2005, Chuck Swiger wrote: >> rsync complains when the filesystem changes underneath it, but it will continue >> to run. On the other hand, rsync is not going to safely maintain the >> referential integrity of a complex file like a live database, but it's okay for >> most other things including mbox's. > > Does it simply complain, or does that somehow alter (lessen) the integrity > of the sync that is going on ? The files which it notices are either copied or noticed as being missing. Any new files which get created after rsync does it's first scan are not going to be picked up later on by rsync. >> rsync'ing a snapshot is a fine idea. > > Ok - because _nothing_ would change, and thus rsync would not complain, > etc. My gut is that while rsync performance might be increased, > filesystem performance would be about the same, since all destructions and > changes on the underlying filesystem are still being committed to the > snapshot ... can you think of a reason why this would not only increase > the rsync performance, but the overall FS performance while rsyncing ? No. The point of using snapshots is to address the integrity concern above, they don't do anything in particular to change the performance. If disk I/O is a significant concern to you, add more spindles, use RAID-1 or RAID-10 configurations, or some combination of the two. >>>Finally, am I correct that there are _only two_ rsync comparison methods - >>>the default checksum method, and the --size-only method ? Am I correct >>>that rsync _always_ looks at the timestamp first, and then applies either >>>checksum or size comparison ONLY IF the timestamps are different ? >> >> No, rsync checks both timestamp and size or checksum. > > So you are saying even if the timestamps are identical, rsync will _still_ > do either a size or checksum comparison ? That seems ... inefficient > ? Is there a way to tell it "if the timestamps are identical, just move > on" ? What happens if a program appends some more data during the same second? rsync has to fstat() the file anyway which potentially involves a disk operation, once it's done so, comparing both timestamp and size doesn't take a significant amount longer to do. -c, --checksum skip based on checksum, not mod-time & size -- -Chuck