From users-return-4065-daniel=haxx.se@subversion.apache.org Mon Aug 2 22:56:28 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o72KuRUo020293 for ; Mon, 2 Aug 2010 22:56:28 +0200 Received: (qmail 15446 invoked by uid 500); 2 Aug 2010 20:56:18 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 15439 invoked by uid 99); 2 Aug 2010 20:56:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 20:56:17 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=FREEMAIL_FROM,SPF_NEUTRAL,T_TO_NO_BRKTS_FREEMAIL Received-SPF: neutral (nike.apache.org: 208.10.26.74 is neither permitted nor denied by domain of lesmikesell@gmail.com) Received: from [208.10.26.74] (HELO mailmx.futuresource.com) (208.10.26.74) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 20:56:10 +0000 Received: from ns1.futuresource.com ([10.207.192.125]) by mailmx.futuresource.com (8.13.8/8.13.8) with ESMTP id o72KsBoa009557 for ; Mon, 2 Aug 2010 15:54:11 -0500 Received: from [172.22.181.98] ([172.22.181.98]) by ns1.futuresource.com (8.11.6/8.11.6) with ESMTP id o72Ktkg03306 for ; Mon, 2 Aug 2010 15:55:47 -0500 Message-ID: <4C5730D3.8060507@gmail.com> Date: Mon, 02 Aug 2010 15:55:47 -0500 From: Les Mikesell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: users@subversion.apache.org Subject: Re: Support for filesystem snapshots (?) References: <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CB5@DRMBX3.winmail.deshaw.com> <20100802161739.GI3967@ted.stsp.name> <4C56F278.9030904@gmail.com> <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CBC@DRMBX3.winmail.deshaw.com> <20100802175621.GL3967@ted.stsp.name> <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CD7@DRMBX3.winmail.deshaw.com> <20100802202736.GO3967@ted.stsp.name> <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CE1@DRMBX3.winmail.deshaw.com> In-Reply-To: <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CE1@DRMBX3.winmail.deshaw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 208.10.26.74 X-Virus-Checked: Checked by ClamAV on apache.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Mon, 02 Aug 2010 22:56:28 +0200 (CEST) X-Friend: Nope On 8/2/2010 3:46 PM, Vallon, Justin wrote: > From: Stefan Sperling [mailto:stsp@elego.de] >> users asking interesting questions: http://mail-archives.apache.org/mod_mbox/subversion-users/201008.mbox/%3C6EC02A00CC9F684DAF4AF4084CA84D5F01C40CD7@DRMBX3.winmail.deshaw.com%3E >> i dunno how fsfs behaves in face of an interrupted commit; whether or not it needs to be rolled back >> if you haven't touched current than the rev file will never be read and will be overwritten >> stsp: does that answer your question? >> i think so >> because the rev file of the following commit will have the same name to move things into place onto >> write lock only for revprop change and commit >> :-) >> >> Now, how does rsync, or a file-system snapshot, know to make sure that >> 'current' is always copied first? Even if you copy 'current' first manually, >> rsync might later overwrite it. But unless you use packing it's trivial to >> fix the backup if it breaks, and all you risk is losing the most recent HEAD >> revision, which you may not have gotten with a hotcopy anyway. > > When I speak of a filesystem snapshot, I mean an instantaneous copy of the volume (ala NetApp, EMC, ZFS). In this case, there is a guarantee that if we snap the new "current", then we will also have the other files (assuming that they have been flushed, etc, by the client). Further, it sounds like (a) subsequent commits will not run into trouble because of the partial commit, and (b) the repository will not be otherwise affected by a partial commit. > > That means filesystem snapshots pass the transactional test. Maybe - is there a guarantee that the app flushes to disk in the expected order? Or do snapshots take the current dirty filesystem buffers into account? -- Les Mikesell lesmikesell@gmail.com