The original query:
>
> I've been using Backup Copilot on a 4/390 running 4.1.1 last week,
> I was unable to dump the /var partition!
>
> sicsun[19]$ dump 0f - /var > /dev/null
> DUMP: Writing 32 Kilobyte records
> DUMP: cannot lock file system: Deadlock situation detected/avoided
> DUMP: The ENTIRE dump is aborted.
>
>
> Every other file system dumps just fine. I installed the
> following patches to no avail:
>
> unbundled disksuite any 100483-02 Disk Suite Backup Copilot: NFS Jumbo patch
> unbundled backup-copilot any 100551-02 Backup-Copilot 1.0 jumbo patch
>
> I also ran newfs on the /var partition since it might have been
> last formatted under 4.0.x and never been redone since. But the problem
> is still there. Originaly I had put the backup database on /var, but I
> have since moved it to another partition, but again same problem.
> I also moved /var/tmp to another partition and added a symbolic
> link "/var/tmp" to the new location, but again same problem.
Well the solution came from our local Sun support, the file
/etc/dump.conf specifies which filesystem holds the backup database
(filesystem /soft) and it also specifies on the following line what
type of locking to use when backing up that partition, in our case
it is: "lock all" which is the default. If I understood correctly, this
type of locking prevents any change to the database when it is being
backed up which is a "good thing". However, if /var/tmp is unavailable
due to this locking, dump is unable to work.
So my first guess, to move the database to another partition than
/var was the correct one. However when moving the database, one must
remember to modify /etc/dump.conf appropriately which I hadn't done.
I don't know why moving /var/tmp to another partition didn't work, maybe
it checks access to /var rather than to /var/tmp?
One thing to note, is that the error message I got is not documented
anywhere in the Copilot manual nor is there any mention of not putting
the database on /var. In fact, that the problem is due to /var/tmp
being in the same filesystem as the backup database is only a guess,
but changing the backup database of filesystem definitely solves the
problem.
One thing mentionned by Laura Pearlman (pearlman@rand.org) was
whether we were using a file for swapping in that file system. We
weren't, but I don't know what would happen if we were!
I want to thank the following people for their help:
scrottaz@swiss.sun.com
sdo@swiss.sun.com
From: pearlman@monty.rand.org (Laura Pearlman)
From: bill%grape@uunet.UU.NET (Bill McSephney )
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
brossard@sic.epfl.ch
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:53 CDT