Date: Sat, 25 Sep 1999 16:28:53 -0400 (EDT) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: freebsd-questions@FreeBSD.ORG (FreeBSD Questions) Subject: dump(8) Change History, New Change? Message-ID: <199909252028.QAA39375@cc942873-a.ewndsr1.nj.home.com>
next in thread | raw e-mail | index | archive | help
I noticed an undesireable feature in the way dump(8) calculates the
time since last dump using fstab(5) entries on a 2.2.8-STABLE
system. I started a change-request PR, but realized I should probably
use dump source from 3.3-STABLE in my patches. After noticing that
dump had had some changes, it took me a while to figure out exactly
what they meant... All in all, I probably spent two hours figuring out
someone had tried to change dump to fix the problem I had had.
So, first, where can one go to look up the revision history of source?
Is there any other "change" documentation (since this change did not
get mentioned in the manpage)?
Second, from how I read the code, the "fix" is sub-optimal. The
problem I had on 2.2.8 was that 'dump -[wW]' calculates to the second
whether it has been precisely 'x' number of days since the last
dump. Since a cron job runs at pretty much the exact same time
every day, there is the problem when the new dump is calculated as
trying to start (x-1) days + 23:59:59 before the last[0].
In code, here is the change that was made in
/usr/src/sbin/dump/optr.c to get around this,
@@ -501,9 +505,13 @@
date[16] = '\0'; /* blast away seconds and year */
lastname = dtwalk->dd_name;
dt = fstabsearch(dtwalk->dd_name);
- dumpme = (dt != NULL &&
- dt->fs_freq != 0 &&
- dtwalk->dd_ddate < tnow - (dt->fs_freq * 86400));
+ dumpme = (dt != NULL && dt->fs_freq != 0);
+ if (dumpme) {
+ tlast = localtime(&dtwalk->dd_ddate);
+ dumpme = tnow > (dtwalk->dd_ddate - (tlast->tm_hour * 3600)
+ - (tlast->tm_min * 60) - tlast->tm_sec
+ + (dt->fs_freq * 86400));
+ };
if (arg != 'w' || dumpme)
(void) printf(
"%c %8s\t(%6s) Last dump: Level %c, Date %s\n",
Now, what the new code does is take the time of the last dump (in UNIX
epoch seconds) and subtract the hours, minutes, and seconds. This
effectively moves the effective dump time to the local midnight of the
day of the dump. Then, the days in fstab(5) are added, and the time
compared to "now."
This would fix my problem. I want to do daily dumps at about
0300. Since the time of the previous dump will be pushed back to
midnight in calculations, I effectively have a 3 hour pad.
However, if someone were to wish to do dumps at around midnight, they
will still have some interesting problems. The basic idea behind this
change is to put some "pad time" between you and the last dump so that
to-the-second calculations won't mess things up (at least that's what
I would assume the desire was, again, where would the change
documentation be?). The problem with this method is that the size of
the pad varies from 0 seconds to 86499!
I would think a pad that does not vary with the time-of-day would be
more useful, easier to implement, and easier to account for when the
sysadmin plans his backup scheme.
I would suggest a simple constant be put in, let's say two hours,
--- /usr/src/sbin/dump/optr.c Sat Sep 18 23:25:57 1999
+++ dump_new/optr.c Sat Sep 25 16:19:22 1999
@@ -475,6 +475,11 @@
/*
* Tell the operator what to do
*/
+
+/* Padding to give the to-the-second calculation some room to err
+ on the conservative side */
+#define PADSECS 3600
+
void
lastdump(arg)
char arg; /* w ==> just what to do; W ==> most recent dumps */
@@ -508,9 +513,9 @@
dumpme = (dt != NULL && dt->fs_freq != 0);
if (dumpme) {
tlast = localtime(&dtwalk->dd_ddate);
- dumpme = tnow > (dtwalk->dd_ddate - (tlast->tm_hour * 3600)
- - (tlast->tm_min * 60) - tlast->tm_sec
- + (dt->fs_freq * 86400));
+ dumpme = tnow > (dtwalk->dd_ddate
+ - dt->fs_freq * 86400
+ - PADSECS);
};
if (arg != 'w' || dumpme)
(void) printf(
So, does anyone have a reason why the current method is better than a
constant pad? Anyone think this idea is better?
Barring any compelling arguments enlightening me as to why the current
is better than my suggestion, I think I'll put in a change-request PR
on this.
Either way, I think the dump manpage needs a PR to reflect either
option. I'll send in a doc PR for that once I decide whether or not to
do the change-request.
Thanks for any opinions.
[0] Actually, the test is such that 24:00:00 will fail too.
--
Crist J. Clark cjclark@home.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909252028.QAA39375>