From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 16:37:38 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD1D2106569B for ; Tue, 7 Oct 2008 16:37:38 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id 94AF68FC1C for ; Tue, 7 Oct 2008 16:37:38 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by gxk14 with SMTP id 14so6671425gxk.19 for ; Tue, 07 Oct 2008 09:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=LS+tXDlhE2T1inhyZOrWoAVI8C7hOM3NPz4EPEHQIvA=; b=L6dEj3GtJSQSJNJWO+db0FQh42+DQPJEXcCATXJBHfmrKjxJPnc/BiJ2i14Vvsx5Ah u+vGtuYjCZshRDFctCeOev2dCZzZrXrwDRVNN6Jw5n9uFMG2rvhluzBT1BZgIfHBtJ0X ZRsk8HZ51md/ESdOCDAifLiEGxRY7eop8pX8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=lbV7tp43FcqjhutdNKUQRl/rFyuDLu/Lvs+ikyRQkevhDu8mwdMnxBW33M1Vvo05Bb oIwb5lTV7rr8fu5oJYmi1XAkn3u3pWKiwwydDiSF065X+tQczQQurdyKaMkgJ6059nGz NkaclpvxfSdtqarhCQ2remMjChlpg4hhRE+F4= Received: by 10.151.145.21 with SMTP id x21mr10080189ybn.97.1223397457469; Tue, 07 Oct 2008 09:37:37 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Tue, 7 Oct 2008 09:37:37 -0700 (PDT) Message-ID: <5f67a8c40810070937r5ba89773ncee407ace25fa0dd@mail.gmail.com> Date: Tue, 7 Oct 2008 12:37:37 -0400 From: "Zaphod Beeblebrox" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <861vysiv9i.fsf@ds4.des.no> MIME-Version: 1.0 References: <48E9E1BB.6020908@ispro.net> <48EA56BB.6040702@vwsoft.com> <48EA8B3A.3090609@ispro.net> <861vysiv9i.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Volker , Evren Yurtesen , hackers@freebsd.org Subject: Re: continuous backup solution for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2008 16:37:39 -0000 I wanted to respond to DES' email separately --- because he's right. On Tue, Oct 7, 2008 at 5:56 AM, Dag-Erling Sm=F8rgrav wrote: > Evren Yurtesen writes: > > They actually do not think that it is an easy job to adapt their > > software to support FreeBSD even. See this post: > > http://forum.r1soft.com/showpost.php?p=3D4224&postcount=3D3 > > All this shows is that they don't know anything about FreeBSD at all > (plus they need a refresher course in OS design; Linux is also a > monolithic kernel) A very succinct way of making a similar poing :) > What really annoys me with this thread is that nobody has provided any > information at all that would allow someone to understand what needs to > be done and estimate how hard it would be. Well... I hinted that a hammer port would be sufficient (although they need to finish their replication design) and I hinted that the hammer approach may be graftable to ZFS. Both reasonably large effort-wise (but probably within the scope of a single developer with sufficient time). My primary concern about hammer is it's floating history stuff. It seems t= o me that legal compliance might have some things to say about it. It seems (from the document --- I havn't read the source) that the tunability of the "real deletion" of data are "goals" not absolutes. This is a concern. But as filesystems _are_ databases and as they grow database technology (like transactions and B+tree indexes), we should look to database systems for some of the solutions (ie: problems already solved). Replication replacing "mirroring" is just one of them. Doing this at the block level was suggested by someone earlier (BTW). Suggesting that a geom node could store a bit or two per bock (marking it "dirty" prehaps) and shipping off the blocks. That only solves the replication. You'd need something like a transaction ID per block stored o= n the backup server to enable time travel. Probably want a B+tree index ther= e too. If you're not careful, you might find implementing the filesystem solution much easier. You could, however, implement this with hooks for gjournal --- such that the filesystems you backup are always sane.