xfs
[Top] [All Lists]

Re: xfsdump fails to overwrite stream terminator - dumps lost

To: Mandy Kirkconnell <alkirkco@xxxxxxx>
Subject: Re: xfsdump fails to overwrite stream terminator - dumps lost
From: Jeremy Jackson <jerj@xxxxxxxxxxxx>
Date: Tue, 25 Nov 2003 14:34:59 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <3FC398C2.8010407@sgi.com>
References: <005f01c3aacb$653522d0$6207a8c0@titanic> <3FC398C2.8010407@sgi.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
Hi Mandy,

I'm a bit confused. The problem occurs on multiple systems when using xfsdump 2.2.14 on a blank tape. The first fs dumps ok, but the rest just keep overwriting the second session.

The *older* versions seem to work, in fact I have switched 7 or so systems to the 2.2.11 since it's the only way I can do backups.

Sorry if my post was a bit confusing... I made a second post with some newer information. It looks to me like 2.2.12 was a regression, not a fix.

Regards,

Jeremy Jackson

Mandy Kirkconnell wrote:
Jeremy Jackson wrote:

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.


As you suspected, this is caused by the problem that got fixed in 2.2.13. It's a nasty one! Any tape backups written with 2.2.12 or earlier are not reliable when multiple dump sessions are involved.

The problem was introduced when xfsdump was ported from IRIX to Linux. On IRIX, the TS tape driver sets EOF whether it is to the left OR right of a tape mark. On Linux, the ST tape driver ONLY sets EOF when positioned to the right of a tape mark. On IRIX, the MTBSF,1 (backward space 1 filemark) ioctl moves backward along the tape until it finds a filemark, then positions the tape to the RIGHT of (after) the filemark. On Linux, the MTBSF,1 ioctl moves back one filemark and positions the tape to the LEFT of (before) the filemark. These differences are very important!!

These filemark positioning differences were causing the tape to be rewound before each dump and the next dump would begin at the exact same start position of the last dump. The result of this was that each new dump would always overwrite the previous dump, so a tape would only ever contain one full (most recent) dump session at a time!!

Please use 2.2.13 or later for any new backups.

Thanks,
Mandy




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