Well, something strange is going on and I no longer think it has
anything to do with amanda.
Here is a segment of the report from amanda from my latest backup:
DAILY01 0:04 16776767k 100.0 9 9
DAILY02 0:04 16777056k 100.0 0 1
So amanda definately thinks it's writing 16Gb to each virtual tape even
though the du command says the virtual tape slot has 25Gb:
$ du -sh /vtapes/DailySet1/slot1
25G /vtapes/DailySet1/slot1
However, if I copy slot1 to another computer via scp, scp reports that
it transfered 16Gb of data. And du on the other computer says 16Gb. The
virtual tapes are on a remote file system mounted via NFS. So either
writing to an NFS volume expands a file by 50% or (more likely) the du
command does not correctly report file sizes on NFS mounted file systems.
Anyway, I think that this whole time, the problem was the du command or
maybe NFS and not amanda.
On 10/25/13 13:19, Jean-Louis Martineau wrote:
Hi John,
It always works for me.
I found a bug, it randomly (not that random) take the value of the
tapetype length or the device max-volume-usage property.
In my case, it always use the value of the tapetype length, in your case
it always take the value of the device max-volume-usage property. Sine
your max-volume-usage is 0, it have no limit.
Can you retry by setting the tapetype length and the device
max-volume-usage property to the same value
(max-volume-usage is in bytes).
The attached path fix the bug.
Jean-Louis
On 10/25/2013 12:49 PM, John G. Heim wrote:
But that same man page also says, that for the vfs device, "This
device supports the ENFORCE_MAX_VOLUME_USAGE property. Default value
is true."
Furthermore, the man page says that if ENFORCE_MAX_VOLUME_USAGE is
false, the volumes expand "without limit". But that's not what is
happening. They are consistently expanding to 150% of the tape length
parameter. Like I said, I even predicted that if I set the tape length
parameter to 16386 megabypes, it would end up writing 25G to each
volume. That was based on the fact that when I set it to 25600
megabypes, it wrote 38G to each volume.
That same man page also says, "Device properties specified outside of
any device definition apply to all devices." Maybe I'll try setting
MAX_VOLUME_USAGE and ENFORCE_MAX_VOLUME_USAGE in my amanda.conf and
see what happens. I will bet that setting ENFORCE_MAX_VOLUME_USAGE to
true will have no effect.
One thing that does strike me as odd is that I'm not seeing other
questions of this nature while searching the list archives. Maybe it
is something weird abut my set up. I'm running debian wheezy and
whatever amanda is in debian wheezy. The machine was running debian
squeeze last week. Amanda exhibited the same behaviour in squeeze as
it is doing in wheezy. I finally upgraded from squeeze to wheezy
partly because of this problem. But maybe some misconfiguration got
dragged along. But how would the vfs device have gotten
misconfigured. I sure didn't do that.
On 10/25/13 10:02, Jean-Louis Martineau wrote:
man amanda-devices
MAX_VOLUME_USAGE
(read-write) On devices that support it, this property will
limit
the total amount of data written to a volume; attempts to
write
beyond this point will cause the device to simulate "out of
space."
Zero means no limit. The tapetype parameter length sets
this
property.
ENFORCE_MAX_VOLUME_USAGE
(read-write) If this property is false, limit set by
MAX_VOLUME_USAGE property (and thus the tapetype LENGTH
parameter)
will not be verified while writing to device, allowing the
volume
to expand without limit. If this property is true, then
MAX_VOLUME_USAGE will be enforced, limiting the total size
of the
volume. This property is not available on all devices; see
below.
Set the ENFORCE_MAX_VOLUME_USAGE
The tapetype length is use in the estimate phase, so it must be the same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape size. Well, I
wouldn't say I resolved them but I think I have one clue. One of the
things I asked about is the meaning of the "length" parameter for a
tape definition. I had set it to 25G for my virtual tapes but amanda
was writing 38G to each vtape. This was going to be a problem
because I have a quota on my virtual tape file system of 2Tb and I had
therefore calculated that I could create 80 25Gb tapes. Here is what
the amanda.conf man page has to say about the tape length parameter:
> length int
> Default: 2000 kbytes. How much data will fit on a tape, expressed in
> kbytes. Note that this value is only used by Amanda to schedule which
> backupswill be run. Once the backups start, Amanda will continue to
> write to a tape until it gets an error, regardless of what value is
> entered for length (but see amanda-devices(7) for exceptions).
The device for virtual tapes is vfs-disk or something like that. But I
couldn't find anything in the docs for how it determines how much to
write to a vtape. If it keeps writing until it got an error, in my
case, it would write over 2Tb until it hit the hard quota on the
filesystem. So that couldn't be.
Then it occured to me that 25 * 150% = 38G. . Coincidence? I
recreated the vtapes with a size of 16Gb. Now amanda is writing 25Gb
to each tape. My first backup wrote to 11 tapes. Slots 1-10 have 25Gb
on them with 19G on the last. The amount of stuff on tapes 1-10 is
not exactly the same on each tape but it's a little over 24G each.
IMO, this borders on a bug. The wiki strongly implies that you can
take your disk file system size and divide by the number of tapes to
get the tape size. While the amanda developers aren't responsibe for
the wiki being misleading, it is natural to assume the length
parameter for a virtual tape is the actual size of the tape. I'm not
the only one who made that assumption, so did whoever wrote the wiki
entry on virtual tapes.
Anyway, I'd still like to know how amanda determines when to stop
writing to a vtape. I can put comments in my amanda.conf to say that
the tape length is set to 16G so amanda writes 24G to 25G to each
tape. But that's hardly an ideal solution.
--
---
John G. Heim, 608-263-4189, jh...@math.wisc.edu
