Hi everyone,
For some reason support calls I resolve seem to take the longest time
to fix. Anyway the upshot is (as Daniel Monjar found out)
that Compaq decided that the behavior of vdump, in some recent
patches to it (in 4.0D pk4 and 4.0E pk1/pk2, among others) should
be changed so it resets the atimes of files. Compaq have now
decided that this is actually not so smart as it doesn't understand NFS
and gives this error message when it tries to reset atimes of files
on NFS volumes. The solution is either:
(1) revert to the unpatched vdump or
(2) get a new patch from Digital which will undo the atime thing while
retaining the other features the patch contains (dunno what these are).
Digital have this new patch but they may have to port it to your
version/patch level of Unix which seems to take a few weeks
(hence the late summarizing). They certainly have one for
4.0E pk2 as that's what I have.
To quote:
>Hello John. Engineering has completed the port of the vdump
>patch to 4.0E patch kit #2. The vdump binary will no longer
>attempt to update the access times on files backed up on an
>NFS filesystem. The patch is available from:
> ftp://xfer-alf.service.digital.com/to_customer/C990823-5010.tar.gz
>and includes a new version of vdump and a README describing
>the installation procedure. Note that the fixes included
>in this binary will be present in patch kit #3 when it's
>available, so you can safely install that patch kit to get
>the "official" version of vdump.
Thanks to all who replied. Background story below.
John
John Speakman wrote:
> pursuant to the below, Compaq's tech support's rather lame answer
> is that, well, vdump isn't really for NFS file systems (although if you
> do a "man vdump" it says "However, the vdump command is file-
> system independent, and you can use it to back up other file systems,
> such as UFS and NFS") and they "guess" that it's "probably" a bit
> fussier in 4.0E than 4.0B about handling NFS stuff. Anyway they
> recommend backing up the AdvFS domains on which the NFS
> filesystems are mounted rather than the NFS filesystems themselves,
> which is of course a monster pain in our environment which is why
> we did it using NFS in the first place. They suggested other iffy
> approaches like using rsh and concluded by suggesting we buy
> Legato Networker.
>
> > Hi everyone,
> >
> > since moving from 4.0B to 4.0E we have been seeing the following
> > message in our backup logs:
> >
> > vdump: can't reset atime for <./pathname/.filename>; [22] Invalid argument
> >
> > where /pathname/filename is the correct path to the file it's backing up.
> > It
> > happens on ASE mounted NFS volumes only (AdvFS volumes are OK).
> > I couldn't swear it happens with every single file on each NFS volume but
> > certainly a huge number of them (the reason I noticed is that the volume
> > containing our backup logs filled up). Anyway it seems what it's doing is
> >
> > backing up the file OK (I hope! I will try a restore next) but then trying
> > to
> > set the archive bit or whatever and failing because (I guess) one of the
> > arguments is now no longer valid on NFS volumes. Here's an example
> > of the vdump command we use:
> >
> > vdump -0uN -f /dev/nrmt0h /usr/users
> >
> >
> > John
Received on Tue Sep 21 1999 - 17:35:02 NZST