From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 02:56:07 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D50916A404 for ; Sat, 21 Apr 2007 02:56:07 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 32F2613C48A for ; Sat, 21 Apr 2007 02:56:07 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id ED16C5BA9; Fri, 20 Apr 2007 19:38:32 -0700 (PDT) To: Mike Wolman In-reply-to: Your message of "Sat, 21 Apr 2007 02:25:47 BST." <20070421021529.R16230@nux.eros.office> Date: Fri, 20 Apr 2007 19:38:32 -0700 From: Bakul Shah Message-Id: <20070421023832.ED16C5BA9@mail.bitblocks.com> Cc: freebsd-fs@freebsd.org, ticso@cicely.de Subject: Re: lazy mirror / live backup 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: Sat, 21 Apr 2007 02:56:07 -0000 > >> My only concern is zfs is quite heavy weight (memory wise) compared to > >> gmirror and ufs for a simple laptop/desktop setup which you may just want > >> to replicate the entire drive and grab the ggatec device and be ready to > >> run should anything happen to the machine. If you are using a mirrored device, you just need to keep track of changed block numbers -- no need to get down to sector numbers or even fragments. Assuming 16KB block size you need to find disksize/16384 bytes somewhere for a bitmap of changed blocks. This is not too onerous. Probably a variation of ggatec. And you can let a user mode program send them to a remote site. > > vbackup from devel/plan9port stores checksums and allows offering > > only different blocks to the other side. > > venti - the backing store behind vbackup - allows compression and > > single storage of different blocks with same data, which reduces > > the required backup capacity very impressive. > > My expirience with vbackup is that this mechanism is fast enough > > as long as there are no hughe differences. vbackup is a good replacement for dump. But it will read all the blocks in use (even if after the initial dump most of them won't be written to venti). This means for very large disks it will take a long time. For instance, on my laptop vbackup does a little over 1GB/minute. If we can combine vbackup with a bitmap of changed blocks it can go much faster!