Hi,
I was experimenting with xfsdump, when something odd happened.
I have done dumps of the filesystems of 3 machines to a common tape drive,
an Exabyte EXB-8500. One machine contains the tape drive, the other two use
rmt. Five tapes were filled (5GB each), with a sixth only partly used.
Next I wanted to test overwrite handling, as I was having problems with an
earlier version of xfsdump. I started a dump of a 75GB filesystem, without
using the -o flag. I began with the partly used sixth tape. The previously
used dumps had apparently left a stream terminator at media file 12, and
this is where the dump began.
After the tape became full, a tape change was requested. I either felt like
testing xfsdump, or I wasn't thinking clearly, so I accepted the tape change
request without changing the tape. As I watched "xfsdump: preparing drive",
the tape was rewound, and media files were examined. I was shocked to see
it continue dumping at media file 12 *again*. It found a stream terminator,
and that was all it was waiting for!
I noticed a bug was fixed in 2.2.13 regarding handling multiple backups to a
single tape, but I'm not sure what the exact problem was that was fixed.
The earlier dumps on the tapes were with the older version, 2.2.11-1, and
the *dump in question* was with 2.2.14-1.
Examining the inventory records, it appears that several previous dumps had
done the same thing: overwrite starting at media file 12. Checking the
script output of the backups confirms this. This does not give me a warm
fuzzy feeling.
If anyone can help explain what is happening I would appreciate it. Could
read-ahead or async-writes be causing problems?
My tape drive configuration is as follows:
Exabyte EXB-8500
stinit.conf:
{buffer-writes read-ahead async-writes}
manufacturer=EXABYTE model = EXB-8500SMBANXH1 {
can-bsr
mode1 blocksize= 245760
}
command used:
xfsdump -b 245760 -f /dev/tape -l 3 -p 600 -e -L series0day0 -T
/backup/data
/dev/tape -> /dev/tapes/tape0/mtn
Thanks,
Jeremy Jackson
|