Jon,
There is no good short-term solution to this problem. Sorry. :-( Tape spanning
helps, but is not a panacea.
This is one of the limitations of the vtape API that I was talking about -- it
tries to reimplement tape semantics on a filesystem, even when that doesn't
make sense.
When the Device API is done, this problem will go away, though the combination
of two new features: Partial device recycling means that you can delete only
certain files from a virtual tape: This would include failed dumps, but might
also include old dumps. The second new feature is appending to volumes, which
I hope is self-explanatory.
With the combination of these two features, the future of disk-based storage
is that you will have only one virtual tape (a "VFS Volume"), to which you
constantly append data at the end and recycle data from the beginning. This
makes a lot more sense in terms of provisioning space, as well as making use
of provisioned space. Also, with only one volume, you no longer need the
chg-disk changer, which simplifies setup quite a bit.
Besides the Device API bits, which are mostly only interesting to developers,
there will need to be discussion in the community about the right way to
do the user side of these features: In particular, partial volume recycling
will require rethinking Amanda's retention policy scheme. One possibility
(but not the only one) might be to talk about keeping a particular dumptype
for a particular number of days. Now might be too soon, but at some point I'd
like to discuss this with you in greater detail.
Cheers,
--Ian
On Tuesday 23 May 2006 16:28, Jon LaBadie wrote:
> I'm running vtapes on a new server. The vtapes
> are split across two external disk drives.
>
> Realizing that some tapes would not fill completely,
> I decided that rather than define the tape size to be
> exactly disk/N, I would add a fudge factor to the size.
>
> Things worked exactly as anticipated. The install has
> now reached beyond the last tape which ran out of disk
> space just before it ran our of the last tapes' length.
> And as usual, the taping restarted on the next vtape
> on the disk with remaining space.
>
> But running out of disk space caused me to look more
> closely at the situation and I realized that the failed
> taping is left on the disk. This of course mimics what
> happens on physical tape. However with the file:driver
> if this failed, and useless "tape file" were deleted,
> it would free up space for other data.
>
> Curious, I added up all the sizes of the failed, partially
> taped dumps. They totalled 46+ GB. That is substantially
> more than I dump daily.
>
> Has anyone addressed this situation?
>
> Before you ask, no I've not gone to tape-spanning (yet).
--
Forums for Amanda discussion: http://forums.zmanda.com/
|
