Hello,
Well: I got no solution for this. I was told that what I see could
really be a race condition or a bug. I'm doing the backups during the
night when the filesystem is mostly quiet anyway but still this is
not a satisfactory condition.
Thanks to all who replied: alan_at_nabeth.cxo.dec.com
Julian Rodriguez <Julian.Rodriguez_at_digital.com>
I'm attaching their replies followed by my original posting below.
Tom
---------------------------------------------------------------------------
From alan_at_nabeth.cxo.dec.com Sat Apr 18 11:34:01 1998
Subject: Re: GTAR on Clone Filesets anyone ?
The race condition is possible, or it could be a bug. AdvFS
views file system data as "pages". A small file may be a
fragment of a page or a small number. A large file is many
pages. Only the page which is changed has the original data
copied to the clone. I can imagine a bug where the file
system doesn't remember that it already copied a given page
and copies the 2nd generation data when it changes a 3rd
time. That would be easy to test.
---------------------------------------------------------------------------
From: Julian Rodriguez <Julian.Rodriguez_at_digital.com>
Subject: RE: GTAR on Clone Filesets anyone ?
Thomas,
a clone fileset is only a statical photo of the a fileset at a given
time. To preserve integrity of the photo, when a file in the original
fileset is changed, the old file is copied to the clone fileset, so you
were right in your conclusion.
By the way, "vrestore -t" shows the names and sizes of files without
restoring them.
Julián Rodríguez
UNIX Ambassador & RDBMS Specialist
Technical Support Group for Spain
*+34-(9)1-583.41.92 DTN: 874-4192
Fax: +34-(9)1-734.88.34
*julian.rodriguez_at_digital.com
------------ O R I G I N A L P O S T I N G -----------------------------
Hi,
I thought I'd understand AdvFS clone filesets and now this: Last
week I decided to switch to clone filesets for my nightly backups
of your main user domain mainly because I do a gtar backup followed
by a "gtar -d" compare run and some people tend to leave some stuff
running over night causing the compare run to report errors. So
a clone fileset seems to be the natural solution for this, I thought.
But: The gtar compare run still gives me lots of errors like this:
home_clone/users/proj/wiis/dist/2.0.9/RELEASE.NOTES: uid differs
home_clone/users/proj/wiis/dist/2.0.9/mktape.acg: uid differs
home_clone/users/proj/wiis/dist/2.0.9/mktape.sun.sbg: uid differs
and this:
home_clone/users/proj/sedavis/src/Sedavis.jar: data differs
The "uid differs" error does'nt sound so terrible but the "data
differs" error does!
I got lots of "uid differs" but only 20-30 or so of "data differs".
I've checked all files with "data differs" errors and indeed they
have all been modified during the time of the backup!! So what?
I thought that the clone fileset would have a copy of the original
data at the time the clone fileset was created?
Likewise I can't explain the "uid differs" errors. There are files
which exactly the same gid/uid in the backup which DON'T have this
error reported. Others with the same gid/uid get an error reported.
Now this is rather peculiar, isn't it. My one and only possible
explanation for this phenomenon is this: When a file in the original
fileset is changed, the old file is copied to the clone fileset.
If gtar happens to access this file at the very same moment it
gets the newly & changed file data rathern than the old data which
it ought to get. Typical race condition. Again this is only my
attempt of an explanation.
Now maybe vdump can cope with this BUT the big problem I have with
vdump is that there is no way for verifying the backup on a file by
file basis. This is why I still use gtar for this.
Any ideas anyone? Are my assumptions correct? Any other comments?
Thanks a lot -- Tom
BTW: For the case it matters somehow: This is all under DU 4.0D with
the latest version of gtar from the gnu sources.
--------------------------------------------------------------------------
T o m L e i t n e r Dept. of Communications
Graz University of Technology,
e-mail : tom_at_finwds01.tu-graz.ac.at Inffeldgasse 12
Phone : +43-316-873-7455 A-8010 Graz / Austria / Europe
Fax : +43-316-463-697
Home page :
http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on :
ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send
mail with subject "get Thomas Leitner" to pgp-public-keys_at_keys.pgp.net
--------------------------------------------------------------------------
Before we have the paperless office, we have the paperless toilet!
Received on Sat Apr 18 1998 - 11:40:34 NZST