Veritas-bu

Re: [Veritas-bu] Quick Erase Question

2008-07-02 11:54:53
Subject: Re: [Veritas-bu] Quick Erase Question
From: "Paul Keating" <pkeating.list AT gmail DOT com>
To: Veritas-bu AT mailman.eng.auburn DOT edu
Date: Wed, 2 Jul 2008 11:29:48 -0400
Exactly.
unless you maintain a VERY small Scratch pool and a decent about of
free space, you will run out of space to write to, as the VTL still
has space reserved for tapes that Netbackup thinks are Scratch.

if you're using 6.5, I think there's a Scratch notify script that gets
called after a cart goes to scratch, and gets the media ID as an arg.
in that case, it's braindead easy to add a line to the script that
calls a bplabel against that ID.

with 5.x
I use the following script and call it from a session_notify:

#!/bin/sh
# This script generates a list of media located on VTL which have expired and
# have been returned to the Scratch pool since the last time the script was run.
# It should be called on a regular basis from cron, or by a Netbackup session
# notify script.
# Assumes /usr/openv/volmgr/tmp exists, and contains a file called prev.scratch
# which contains a listing of the scratch tapes labelled on the previous batch.
# Also, assumes this script is run as 'root'
# Note in the environment for which this was created, all Virtual Tape
Media IDs are
# prefixed with VT
# vmquery provides a list of all tapes in Scratch pool and residing in the VTL
# and dumps this list to a temp file.
/usr/openv/volmgr/bin/vmquery -pn Scratch -b | grep VT | sort | awk
'{print $1}' > /tmp/all_scratch.tmp
# diff compares the curent list of Scratch to the list from the previous
# iteration of this script and stores the new IDs in a new temp file
/usr/bin/diff /usr/openv/volmgr/tmp/prev.scratch /tmp/all_scratch.tmp
| grep ">" | awk '{print $2}'  > /tmp/recent_scratch.tmp
# The script is finished with the previous iteration's info, so we clean up
/usr/bin/rm -f /usr/openv/volmgr/tmp/prev.scratch
# we now bplabel all of the new Scratch media
for i in `cat /tmp/recent_scratch.tmp`; do
/usr/openv/netbackup/bin/admincmd/bplabel -m $i -d dlt -o -p Scratch;
done 2>&1
# Once the bplabel is complete, we take today's list of total Scratch and store
# it as prev.scratch for the next iteration.
/usr/bin/mv /tmp/all_scratch.tmp /usr/openv/volmgr/tmp/prev.scratch
# We also clean up the list of today's unique scratch
/usr/bin/rm -f /tmp/recent_scratch.tmp


On Wed, Jul 2, 2008 at 10:57 AM, Ellis, Jason <jellis AT abaris-inc DOT com> 
wrote:
> No it doesn't, as the DDR cleaning cycle will only clean those blocks
> that can be erased since the data no longer exists. Data that is still
> duplicated somewhere on the DDR is left alone. Those blocks that can be
> cleaned are less likely to be duplicated since they can be cleaned so
> quickly, stale data, on the other hand, like file system files, will be
> around forever.
>
> Part of the problem in going with the VTL option of the DDR is that you
> have to still manage tape in that you want a very small scratch pool
> tape rotation to maximize your DDR file system cleaning cycle. With the
> NAS option this would all be transparent, but with the VTL option the
> data on a virtual tape is only marked available for cleaning when the
> file is truncated. The best way to truncate the file is to run a quick
> erase, which essentially re-writes the headers of the virtual tape.
>
>
> Jason Ellis
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

<Prev in Thread] Current Thread [Next in Thread>