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 <kperry@daotechnologies.com> 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. -- Rich ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug