[rbldnsd] Idea for cleaning up forked child when reloading parent dies

[Victor Duchovni]

On Wed, Apr 27, 2005 at 10:24:46PM +0400, Michael Tokarev wrote:

> >> prepare_new_file(file.tmp);
> >> fd = open(file);
> >> rename(file.tmp, file);
> >> pwrite(fd, 0, 1, offsetof(active_flag));
> >>
> >
> >    /* The locking code, must stat(2) the file after
> >       obtaining the lock, to make sure it has not moved */
> >    fd = prepare_new_locked_file(file.tmp);
> >    ... populate and flush tmpfile ...
> >    pwrite(fd, 0, 1, offsetof(active_flag)); /* mark active */
> >    fsync(fd);	/* Force all data and metadata to disk */
> >    rename(file.tmp, file); /* Rename with lock still held */
> >    close(fd);	/* This releases the lock */
> >
> >The file must be crash-proof once it is marked active. The version
> >you suggest is not atomic, but the idea is the same...
> 
> Crash-proof?  You mean, to stay after power failure for example?
> It's easy to achieve by running something during startup -- to
> force re-create the file for example.

If the machine reboots and the file has the active flag set, it must
be immediately usable. The rebuild of the next file can happen in the
background. So file data must be on disk (fsync) with the active
flag set before the file is renamed.

If the input format could be revised to make the rsync be append-only
(adds/deletes at the end of the file). The server could remember the
length of each source file when last read and just import the new data
at the end without scanning the whole file. Periodically the stale data
is garbage collected by delivering an updated generation number file,
which forces a full rebuild (say once a week). One model is that each
source file is instead a directory, consisting solely of append-only
files. When enough garbage accumulates, the current file is deleted and
a new denser file with a new name is created in its place.

If we enlarge the problem definition to include not just rbldnsd, but
also the distributed syncronization problem solved via rsync, we may
come with a better solution.

One still needs to handle atomic large rebuilds when incrementals
run out of steam, but the frequency can be much lower.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.