ADSM-L

if ( timestamp-p ( and ( not ( scheduler-p )))) { happy(); }

2005-05-24 08:48:09
Subject: if ( timestamp-p ( and ( not ( scheduler-p )))) { happy(); }
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 24 May 2005 08:47:56 -0400
... Sorry for the mixed metaphor.

Anyway, I was hoping that someone had found an undocumented option which
activated the 'timestamp output lines' behavior the scheduler evinces.

Mr. Sims' quickfacts ( http://people.bu.edu/rbs/ADSM.QuickFacts; hard to
mention this too frequently ) mentions this in passing, detailing several ways
that don't generate timestamps.

I'm playing some games with some backups run from cron (or actually, at this
moment from my shell) and I would dearly love to know to within a few seconds
when various TSM client processes thought they sent "file <x>".



For the morbidly curious:

We're working on a scheme whereby we'll have nearly "continuous backup"
coverage for a filespace using only stock TSM bits and pieces.  Essentially,
we're collecting lists of files which have been modified, and running
incrementals -filelist=[foo] to catch only the changed bits, yet still make
use of basic TSM codepaths to do so.

We were going to point the filelist at a FIFO, but the TSM client claims not
to be able to do that, and support got petulant when I asked them to prove
they knew what a FIFO was.  They haven't called back for a bit. :)

So, I'm running microsocpic incrementals every few minutes, but also running a
conventional incremental beside them.  All of these are running under
memoryefficientbackup=yes.

But that still means there's opportunity for both processes to back up the
same file.  We think we've quantified this (it happens about one time per
million objects on my filesystem, nightly) but I'd love to be able to use the
timestamps on the logs to help refine our understanding of the process.



- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>
  • if ( timestamp-p ( and ( not ( scheduler-p )))) { happy(); }, Allen S. Rout <=