Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sbin/dump
> 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.
Home |
Main Index |
Thread Index |
Old Index