From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chinner Subject: Re: bdar: efficiently backup allocated bytes in file systems Date: Wed, 19 Mar 2008 10:52:01 +1100 Message-ID: <20080318235201.GE155407@sgi.com> References: <47DF1737.2050700@zabbo.net> <20080318213543.GC155407@sgi.com> <47E03CE3.3080903@zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Chinner , linux-fsdevel@vger.kernel.org To: Zach Brown Return-path: Received: from relay1.sgi.com ([192.48.171.29]:37280 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753523AbYCSTgE (ORCPT ); Wed, 19 Mar 2008 15:36:04 -0400 Content-Disposition: inline In-Reply-To: <47E03CE3.3080903@zabbo.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Mar 18, 2008 at 03:06:27PM -0700, Zach Brown wrote: > > > 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 :) /me grins > Does xfs_copy tend to assert the XFS file format in the backup files it > generates? Yes. If the destination is a file, the resultant image is a sparse file that is a mountable XFS filesystem. > 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. Yup - the use of a sparse file avoids the need for an internal map. But that does't really work for piping the output, though. xfs_metadump is probably more similar to bdar in that respect, but it doesn't copy data.... FWIW, xfs_copy is really for efficient duplication of one source disk to many destination disks in manufacturing, not so much as a filesystem backup tool... > 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. Can't do everything ;) > But I think I'm fine with that. The value:complexity ratio of this > trivial version is refreshingly large. Agreed. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group