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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 1 Oct 2026 18:30:32 +0000
    From:        "Taylor R Campbell" <riastradh%netbsd.org@localhost>
    Message-ID:  <20261001183032.086B0FA2D%cvs.NetBSD.org@localhost>

  | Modified Files:
  | 	src/usr.sbin/fssconfig: fssconfig.8
  |
  | Log Message:
  | fssconfig(8): Clarify some details.

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 ?

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).

I'm not suggesting this as any kind of immediate requirement, nor expecting
anyone to go implement this, just wondering if it would be possible - if
tmpfs doesn't support it (mfs is not suitable, it needs a configured size when
it is created) then there would be no point even looking.   If it does, it
seems like it might be a nice small project for someone sometime.

In general, a tmpfs is kind of perfect for the use, as as long as the system
is running, its data should be safe - if the system dies during the dump,
and reboots, then the dump is lost anyway, and needs restarting - but the
tmpfs vanishes along with it, just great (nothing related to this for fsck
to need to repair, which there would be with an unlinked file on some other
filesystem.)

kre