Peter:
Thank you for your comments.
Excerpts from transarc.external.info-afs: 16-Mar-94 Re: Finding out
which volum.. Peter [EMAIL PROTECTED] (2674)
> > 1. The backup directory also has the "tapeconfig" file.
> So? Why should backup logs behave differently from fileserver, volserver,
> salvager logs?
I have seen the following reasons:
1. Because of history. By Joe.
2. Because butc is not a server process. By Pierette.
3. Because butc may not even be running on a server machine (perhaps
nor even within the same cell). By Pierette.
If these reasons are still unacceptable, one can always create links in
the logs directory to the butc log files.
> > Dump is location independent at the user level. But butc communicates
> > with the dump at a lower level requiring knowledge of the location of
> > the volume.
> If vos move can lock a volume's location, so can butc. What is the problem
> here?
No problem: in both cases, the volume is locked. Butc locks it at time of dump.
> > 3. The TL log does contain a list of volumes that were dumped as does
> > the backup database. One should be able to move a volume AFTER it has
> > successfully dumped. This would be indicated by the TL log or the backup
> > database (using "dumpinfo -id <dumpid>") for the dump in progress.
> Yes, but why should I have to find out the hard way? Why should I have to look
> at this log at all.
You're right, one shouldn't. There is an entry in the our defect
database for this (#5016 if you are interested). High priority too.
> > 4. A volume is locked only during the dump of that volume and not for
> > the duration of the entire dump. Which is why one is able to move a
> > volume while a dump is in progress.
> Then this is incorrect behaviour. Change it. EITHER the volume is required not
> to move until it is backed up - in which case lock it, OR make butc
> intelligent enough to ask the VLDB where the volumes is at the time when it
> needs it so that locks are not required. Just in case anyone argues that the
> wait for each VLDB request slows down the backup, then keep a queue of locked
> volumes (say 10) which are, locked in advance and ready to be backed up, and
> release the locks when they are backed up.
The initial design thoughts are to take the second approach you have
proposed above: make butc smart enough. I don't wish to get into the
scheduling and prioritizing and resources of project work.
> Full backups take a long time here at Cranfield, and I know we're not that big
> a site. Sometimes I *need* to move volumes during a backup. Last week, because
> we were trying our first (stbutc) automated full dump with our new tape
> stacker, I decided not to run balance to even things out, since I knew that
> vos move would almost certainly cause problems. A partition filled up (yes,
> 111%) from 92% full in one afternoon, and I had real problems getting it
> working again. Moving volumes, using balance or "by hand" is not something I
> do for fun, it's what keeps our user filestore manageable.
Good point. The need for butc to determine the location of a volume at
time of dump increased as sites began to make use of the "balance" tool.
This type of feedback is important.
- John Morin.
[EMAIL PROTECTED]
