Re: CVS commit: src/sbin/dump

[Christos Zoulas <christos%zoulas.com@localhost>]

> On Mar 1, 2019, at 9:43 PM, Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> 
>    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.

I agree with all of that, but all this patch does is::

Before:
$ dump -W
Last dump(s) done (Dump '>' file systems):
> /dev/rdk12    (      ) Last dump: Level 3, Date Wed Feb 27 09:16 2019

After:
$ dump -W
Last dump(s) done (Dump '>' file systems):
> /dev/rdk12    (    /u) Last dump: Level 3, Date Wed Feb 27 09:16 2019

If it does not work properly and it breaks something else, I will revert it.

christos

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