Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mailrus!iuvax!sahayman
From: sahayman@iuvax.cs.indiana.edu (Steve Hayman)
Newsgroups: comp.sys.next
Subject: Avoiding dumping /private/vm/swapfile
Message-ID: <54050@iuvax.cs.indiana.edu>
Date: 10 Aug 90 20:45:16 GMT
Organization: Computer Science Department, Indiana University
Lines: 110

The man page for 'dump' suggests 
    ... Dump should have some file that it consults that contain
    inode numbers, names of files and directories, ... to not dump
    to OD/Tape.  This feature would come in especially handy
    to avoid dumping /private/vm/swapfile ... System administrators
    can get around this by writing a program that changes the
    modification time for the swapfile inode.


You may find that your 22 Mb incremental dumps consist mainly 
of a 21 Mb /private/vm/swapfile, so there is good reason to 
avoid dumping this file if you can.

Resetting the modification time on the swapfile inode is easy
enough with 'utime()' (write a C program to call utimes(), or
use  perl -e 'utime 0, 0, "/private/vm/swapfile";'  ) but this
has the side-effect of changing the inode ctime to 'now', and dump checks
both the mtime and ctime when deciding whether to dump a file.
So your swapfile is dumped even if you did reset the 'mtime'.

You need a way to reset both the mtime and the ctime to some
ancient value.  Unix provides no way that I can see to set the
ctime directly.  I considered writing a program to open the
raw disk file, find the inode, and reset the atime/ctime/mtime
to 0, but this rapidly became very ugly (and besides, I couldn't
get it to work :-).

The only quick solution I could think of is the following
little hack, "zerotime".  Warning.  Use at your own risk.
This program

	a) notes the current system time
	b) sets the system time to 0  (for a very brief period)
	c) calls 'utimes()' to set the access and modification time
	   of the desired file to 0; this has the side effect of
	   updating the inode's inode-change time (ctime)
	   to the current time, which we just set to 0;
	d) resets the system time to the time noted in 'a'.


So I put "zerotime /private/vm/swapfile" in my dump script, and
I no longer do incremental dumps of that file, and my incrementals
are much smaller.

I really don't like the idea of tinkering with the system clock like this.
If anybody has a better way to do this, please let me know; if you want
to live dangerously, feel free to use this program.

..Steve

--- cut here ---
/*
 * zerotime file ...
 * reset atime, mtime *AND* ctime to 0 for a file 
 * we are sneaky. we briefly set the time of day to 0, and then
 * call utime, then set the time of day back.
 *
 * The idea is that you put  'zerotime /private/vm/swapfile' in
 * your dump script, to avoid dumping that file.
 *
 * We really shouldn't be tinkering with the clock like this.
 *
 * Steve Hayman
 * sahayman@iuvax.cs.indiana.edu
 * 1990 08 09
 */

#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>

main(argc, argv)
int argc;
char **argv;
{
    while ( --argc ) {
	zero_time(*++argv);
    }
    exit(0);
}


zero_time ( fname )
char *fname;
{
    struct timeval now;
    struct timezone tz;
    struct timeval zero[2];


    zero[0].tv_sec = zero[0].tv_usec = zero[1].tv_sec = zero[2].tv_usec = 0;

    /*
     * note current system time; set it to 0 (briefly)
     */
    gettimeofday(&now, &tz);
    settimeofday(zero, &tz);

    /*
     * set file atime/mtime to 0
     */

    utimes(fname, zero);

    /*
     * reset system time
     */

    settimeofday(&now, &tz);
}