Re: bin/52432: /etc/dumpdates format egregious

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

The following reply was made to PR bin/52432; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas)
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/52432: /etc/dumpdates format egregious
Date: Thu, 27 Jul 2017 12:14:42 +0700

 The dumpdates file (and all associated with it) needs lots of work.
 It is close to hopeless when dumping filesystems on wedges (what good is
 it knowing that /dev/dk3 was last dumped... when dk3 might be something
 entirely different when the next dump happens.)
 
 What's more, it dates back to the days when dumps were all done to tape,
 and there would be one set of tapes for each filesystem, and (provided
 that one can map device names to filesystems) it worked OK for keeping
 track of what had been dumped where.
 
 These days, I'd guess that more people do dumps like I do, onto a removable
 USB drive - each one of those can handle lots of dumps, for many filesystems,
 and for many dump cycles ... but doing just that means that there's not
 a lot of redundancy (in the tape days, if a tape was found to be bad when
 a filesystem restore was needed, you simply picked the next most recent,
 usually the day before...)
 
 I have a bunch of USB drives I dumps to, and to make that rational, each
 has its own dump sequence (so I do a full (level 0) dump, then some
 incrementals, then another full dump, ...) but not to the same device each
 time, I flip around which drive I am using so no one gets used twice in a
 row, so if one of those fails, there's always the other one, or another...
 
 To make that work with dump as it is, my script has to look and see which
 dumpdates file is in /etc and if it is the wrong one, copy the one that
 belongs to the dump sequence for the output device being used for this set
 of dumps ... it would be much simpler if I could just tell dump where the
 dumpdates file is located .. and then use the one in /etc merely to keep
 track of the last dumps for each filesystem, not for working out which date
 to go back until when doing an incremental dump (ie: provide the data for
 dump W to use, and nothing else.)
 
 I have been meaning to propose some radical work on dumpdates for ages.
 
 I do not buy the "it is the API" for a second, the only thing that uses
 dumpdates is dump (restore doesn't) change dump (keep it able to read the
 old format) and we can make the dumpdates file contain any format that
 makes sense, which the current one does not.
 
 kre