From owner-freebsd-questions Sat Sep 25 13:26: 3 1999 Delivered-To: freebsd-questions@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id CF149155ED for ; Sat, 25 Sep 1999 13:25:59 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id QAA39375 for freebsd-questions@FreeBSD.ORG; Sat, 25 Sep 1999 16:28:53 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909252028.QAA39375@cc942873-a.ewndsr1.nj.home.com> Subject: dump(8) Change History, New Change? To: freebsd-questions@FreeBSD.ORG (FreeBSD Questions) Date: Sat, 25 Sep 1999 16:28:53 -0400 (EDT) Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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