Rich Freeman on 29 Apr 2016 03:29:13 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] disk (filesystem) imaging one liner: corrections and a recent use case

On Thu, Apr 28, 2016 at 4:37 PM, Keith C. Perry
<> wrote:
> Bottom line though, Unix / Linux usually has a numbers of ways to do things and fortunately they all tend to be pretty efficient.  The thing I like about cpio is that is very simple.  The initramfs point is something I forgot about.  I got reacquainted with that when I was playing around with Slackware-ARM awhile back.

There is of course nothing wrong with cpio, but it just tends to be a
bit less penetrable since it doesn't know how to recursively scan a
directory and thus you almost always have to combine it with find,
etc.  These days tar does everything cpio does, but there was a time
many years ago when it was less portable/etc.  In the end their output
is conceptually the same - a stream of files and their metadata.

I do agree with using filesystem-aware tools like
dump/xfsdump/btrfs-send/zfs-send and so on.  Some of these offer
features like atomic operation, or a more efficient way of identifying
modified files due to their integration with the filesystem layer.  A
tool like tar/cpio just has to dispatch a bazillion stat calls to the
kernel to figure out what has changed and it can't take advantage of
any underlying optimization (other than the fact that filesystems try
to optimize the order of scandir to facilitate this).  When you do an
incremental btrfs-send it definitely doesn't go scanning every
directory looking for files - it uses the COW design of the shared
btrees to eliminate branches shared between the original and new
snapshots and this greatly reduces the search space, and it further
can identify the specific nodes/extents that contain changes and never
has to diff/hash files or any part of a file on the source or
destination.  Consideration for efficient and complete backup has been
an element of filesystem design for a very long time, but the tools do
tend to be filesystem-specific.

If your system has 10 filesystems mounted at various points then one
big advantage of a tool like tar is that you can just backup your
files into one tarball across all of them, and if you change your
mount layout the tar will still work fine.  If you're using
filesystem-specific tools then you'll end up having 10 different
backups possibly in different formats to take care of all of that.  Of
course, if your goal is to reproduce the exact same configuration on
restoration then the filesystem backups will probably make that easier
than tar, which will just regurgitate the files on top of whatever
mount layout exists on the destination.  So, it comes down to what
you're trying to accomplish.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --