From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zach Brown Subject: Re: bdar: efficiently backup allocated bytes in file systems Date: Tue, 18 Mar 2008 20:10:33 -0700 Message-ID: <47E08429.9010203@zabbo.net> References: <47DF1737.2050700@zabbo.net> <20080319025843.GE2971@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: Andreas Dilger Return-path: Received: from tetsuo.zabbo.net ([207.173.201.20]:38131 "EHLO tetsuo.zabbo.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933167AbYCSU1d (ORCPT ); Wed, 19 Mar 2008 16:27:33 -0400 In-Reply-To: <20080319025843.GE2971@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > So the question is whether the ".bdar" file is specific to the filesystem > being backed up, and if it only allows backing up the whole filesystem? > Does it create a dense output file or a sparse one? Does it store the > data as chunks of blocks in a full-device map or on a per file basis? Let's see.. yes, yes, dense, full-device. It's a tiny little program, you could read it in 10 minutes :). You'll giggle at how incomplete its knowledge of ext* is. > If you can't restore a .bdar backup file to a smaller device than the > source device that makes it less useful than most of the other tools. It is different in a way that won't satisfy people who want to restore to smaller devices, yes. > The question is whether the 2x speed improvement is worth the lack of > portability compared to even dump? Indeed. For me, in my current situation, it is. - z