Re: CVS commit: src/sbin/dump

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

    Date:        Fri, 1 Mar 2019 11:42:11 -0500
    From:        "Christos Zoulas" <christos%netbsd.org@localhost>
    Message-ID:  <20190301164211.DE6AAFB16%cvs.NetBSD.org@localhost>

  | Use getfsspecname() to fill the filesystem argument in dumpdates.

Is there a reason for that?    It seems like a step backwards to me.

If I follow what that means correctly, it is inserting /dev/dkN in
dumpdates, instead of NAME=foo  ?

That's about the least desirable outcome possible - dumpdates is used
to remember when the various dump levels have been done for a filesystem.
The wedge that happens to have been used when the last dump of a filesystem
was done is nowhere near stable enough to be useful for that purpose.

That is, I dump /home which is on dk6 today.   Tomorrow, after a
reboot, /home is now on dk5 (the tumb drive wasn't plugged in at
bopot time, or something) and I want to do an incremental dump.

The dumpdates record of what and when dk5 was last dumped will have
nothing to do with the dump I did of /home yesterday.

We ought probably be keying dumpdates on a GUID for the filesystem,
but we don't really have those (we should) - the closest we come, which
is almost good enough, is the GUID for the device on which the filesystem
is stored - and we don't always have that either.

kre

ps: note that all I have looked at (so far) related to this has been
the diffs for your commit, but this is something it has been my intent
to eventually work on for ages.    Another thing that needs fixing is
to allow multiple dumpdates files, so there can be several indepenendent
dump sequences happening in parallel (I don't mean at the same instant,
but that I do a level 0 today in set A, tomorrow I do a level 0 in set B,
then the day after I do an incremental based upon today's level 0 (set A),
then an incremental based upon tomorrows the next day (set B), and alternate
between the two, so I have two separate sets of dumps (usually each one
to a different external drive) where it alternates day to day which one is
most up to date.   I currently manage that by simply copying the dumpdates
file I want to use to /etc/dumpdates before I start, then copying it back
again when finished, but that's not an ideal solution.