Re: CVS commit: src/usr.sbin/fssconfig

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri, 02 Oct 2026 03:21:48 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
> That says, in part:
> 
> +  For file system types other than ffs such as msdosfs or ext2fs, which
> +  don't support persistent snapshots, a place for a backing store must be
> +  given explicitly with the -x option to dump(8),
> 
> (where I changed the markup to simple text for the purposes of this message).
> 
> Can that -x option specify a file/dir on a tmpfs ?

Should work.

> If it can, I wonder if it would be possible to have dump(8) when given -X
> (which puts the snapshop on the filesystem in question, and so fails with
> the filesystem types which don't support that) detect that failure, create
> a tmpfs just for the purpose, mount it somewhere meaningless /tmp/randomstring
> probably, put the fss backing store in that tmpfs (which could have its
> permissions set to discourage use by anything else) do the dump, then clean
> it all up again when it is done - just so that there is no need for people
> to work out where is a good place to put the snapshop (there needs to be
> enough space to hold whatever changes while the dump is in progress on the
> filesystem being backed up, tmpfs can just grow until swap space runs out).

You could do that, I expect.

This would limit the volume of writes to the file system, while its
snapshot is configured, to roughly the size of RAM+swap -- and you
might run into trouble if you fill that up, e.g. if ufs_rename fails
in the middle because it can't find room to save one of the blocks it
has to update.  If your swap goes to a file on that file system, it
would probably be bad.

I'm not sure I would use it instead of just `-x /tmp' and I'm not sure
I would want the -X option to do that much magic.  But I don't see any
reason in principle why it wouldn't work.