Subject: Re: file system info tool?
To: Greg Troxel <>
From: Malcolm Herbert <>
List: netbsd-users
Date: 11/06/2004 13:27:40
On Fri, Nov 05, 2004 at 07:23:33PM -0500, Greg Troxel wrote:
|Note that dumpfs != dump (but they are culturally compatible).

ah ... yes, good point

|I've found dump to be pretty interoperable, but you are wise to be wary
|- and should check the combination of interest. For example, I ran dump
|on an SGI/mips box under IRIX, and was able to read it on FreeBSD under
|i386 - different OS, CPU, and endianness. But, basically BSD ffs on
|both - there is a loose de facto standard for BSD dump behavior.

I got stung badly when using a DEC OSF/1 system which we'd upgraded
at some point from 4.0a to 4.0d (I think) ... the system hit the wall
pretty hard at one point and we needed to restore from our dumps ...
needless to say because of the upgrade, we only had our original media
for 4.0a and of course the version of dump on that didn't understand
the dumps we'd made under 4.0d ... that experience may have coloured my
feelings toward dump somewhat, although to be fair that could be DEC's
fault ... :)

|  Are there any benefits which outweigh this problem?
|The biggest benefit for me is that dump doesn't update atimes.

hmmm ... the manual for tar lists and option for it as well, so the
NetBSD version of tar looks to support that now as well ...

|I also really like the 'nodump' flag (see cflags(1)), and use -h 0 to
|have this respected even on full dumps. My disks are bigger than my
|tape drives, and this lets me avoid dumping e.g. gnome/TeX goop in
|/usr/pkg, which I'm going to rebuild rather than restore if my disk
|dies anyway.

pretty cool, but same can be done with include/exclude lists as under
tar.  In some respects I would rate that a better solution, since it's
more obvious and explicit - if filesystem Badness happens, you may lose
that flag ... but then by the same token you could lose the list file
as well, so I guess we're even.

I can't seen a manual entry for cflags(1) on my system, nor on the
NetBSD website ...

|Dump is also traditional in the BSD world. It's how we did backups in
|the 70s, if memory serves me, or at least on 2.8BSD.

fair enough - didn't know this history, to be honest

|In the Linux camp, dump is widely frowned upon, and dump under Linux on
|ext2fs may or may not indeed be unreliable. All my filesystems are ffs,
|so I haven't worried about this.

have vague memories of this ... can't understand why that would be the
case though ...

|On the con side, since dump doesn't use the filesystem to read (hence
|the not updating atime advantage), it can dump active files incorrectly
|on active filesystems. In practice people don't worry about this too
|much, and I rarely hear of trouble.

I guess any filesystem which isn't static is going to suffer from these
problems ... I generally don't worry about it either ...

memory is a vague thing - I seem to recall that dump uses the cpio
format on tape, or is that a completely different thing? You can't tell
I've used just tar all my profesional life since the incident mentioned
above ... :)


Malcolm Herbert                                    System Administrator
ph [990] 54881 rm 28-241                          School of GeoSciences