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 15:06:27 -0700 Message-ID: <47E03CE3.3080903@zabbo.net> References: <47DF1737.2050700@zabbo.net> <20080318213543.GC155407@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: David Chinner Return-path: Received: from tetsuo.zabbo.net ([207.173.201.20]:51548 "EHLO tetsuo.zabbo.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755660AbYCSThe (ORCPT ); Wed, 19 Mar 2008 15:37:34 -0400 In-Reply-To: <20080318213543.GC155407@sgi.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > Neat, Zach. You should look at xfs_copy - it does pretty much this for XFS > filesystems.... haha, yet another round of the -fsdevel XFS drinking game :) Does xfs_copy tend to assert the XFS file format in the backup files it generates? One of the things I was hoping for with bdar was to have the resulting copy image be agnostic. It's just a sparse map with some checksumming, really. That limits what we can do, of course. The current trivial format only has one address space which doesn't fit well with the plans file systems have of working with multiple addressable block ranges. But I think I'm fine with that. The value:complexity ratio of this trivial version is refreshingly large. - z