In an article that has now expired at my site, I asked about two
problems with Backup Copilot - a panic, and a case where even
root could not unlock the filesystem after it had been dumped and left
erroneously locked by dump. I've quoted my original article at the end
of this posting.
birger@vest.sdata.no (Birger A. Wathne) solved the unlocking problem.
I had installed versions of the lockd and NFS jumbo patches that were
incompatible with Backup Copilot. The fix was to replace them with
the Copilot/DiskSuite-compiled versions, 100518-01 and 100483-02 respectively.
Since then all of my many tests of the Copilot dump have worked fine
and the filesystem has unlocked correctly.
For the ifree panic, ats@prosun.first.gmd.de (Andreas Schulz) suggested
a "UFS Jumbo Patch", 100622-01 for 4.1.1 and 100623-01 for 4.1.2.
I haven't tried them yet. I haven't had any more ifree panics (or any other
panics, for that matter) since the one I reported.
Janet Jackson
<janet@cs.uwa.edu.au>
Systems Administrator
Department of Computer Science
The University of Western Australia
-------Start of my original article-------
From: janet@dunnart (Janet Jackson)
Date: 22 Sep 92 08:44:41 GMT
Message-Id: <janet.717151481@dunnart>
Newsgroups: comp.sys.sun.admin
Subject: root can't unlock FS after Backup Copilot dump; also panic ifree
Keywords: Backup Copilot, dump, lockfs, panic, ifree
Well, I finally bought Backup Copilot and I'm testing out its dump(8).
Mostly it seems to work fine, but I've had the following two problems
so far.
[This is on a SPARCstation 1 running SunOS 4.1.1 and Backup Copilot 1.0.
The remote tape drive mentioned below is an Exabyte 8500 with hardware
compression, on a Sun 4/470 running SunOS4.1.1. Both systems have Backup
Copilot kernels, with higher revisions of the NFS jumbo and lockd patches
than those distributed with Copilot.]
1. ifree panic
==============
The very first time I tried it (running as root, level 0 dump of the root
filesystem to /dev/null) the system panicked with
panic: ifree: freeing free inode
After the system came back up I immediately tried it again and it worked
fine, and so have all my tests since then.
2. can't unlock
===============
Two (but not all!) of the times I have run a non-level-0 dump of a user
filesystem (not actually a home filesystem, but that sort of thing), the dump
seems to work but at the end it says something like
cannot lock filesystem: not owner
I think it means it can't *unlock* the filesystem, because "lockfs" reports
that there is a write lock in place, and the filesystem sure acts like
there is.
At first I thought the error occurred because I was running it as "backup",
the user we normally do dumps as (it's in operator group, so can read the
devices). However many other tests as "backup" have worked fine...and get
this: ROOT CAN'T UNLOCK THE FILESYSTEM EITHER.
lockfs -u <filesystem name>
fails with "not owner" (and it ain't no NFS filesystem, BTW).
The only cure I've found is to reboot.
The command lines for the failed dumps were:
/usr/etc/dump.COPILOT 1f /dev/null /dev/rsd0g
/usr/etc/rdump.COPILOT 9bdsf 50 108000 24000 wambenger:/dev/nrst2 /dev/rsd0g
(running as backup, not root). Once I was dumping to /dev/null, once
to a remote tape drive. rdump.COPILOT is a symlink to dump.COPILOT.
Note that I tested the /dev/null one a second time and it worked fine.
Has anyone else experienced either of the above problems? If so, what am
I doing wrong? Any help will be much appreciated. Please email and I
will summarise. My /etc/dump.conf file follows. Note that the /dev/rsd0g
filesystem that gave the locking problem is covered by the "default"
filesystem specifications - ie "all" locking is done.
# /etc/dump.conf for Backup Copilot dump
# Janet Jackson <janet@cs.uwa.edu.au>, 1992-09-22
# Version 1 - initial plug-in of Copilot dump to existing setup.
# Do lots of locking and retrying for now.
# Logical devices - as yet unused.
#sequence exb-8500 wambenger:/dev/nrst2
#sequence exb-8200 wambenger:/dev/nrst0
# Names to mail when dump finishes.
# This could be rather noisy - restricted to janet during testing phase.
#mail operators
mail janet
# Default lock and retry specifications for filesystems.
# During file dump phase, no changes allowed;
# so, I think, no need to retry active files as there won't be any;
# but report them just in case.
# Reset file access times to hide dump's access.
filesystem default
lock all
active size 0 report yes retries 0
reset yes
# Lock and retry specifications for extremely volatile filesystems,
# and for filesystems that dump must write during its operation
# (/ if /var/tmp is on there, /var otherwise).
# Here we allow more activity:
# Delete lock only, and retries as follows:
# For active files size < 500Kb, retry twice, don't report.
# For active files size >= 500Kb, retry once, do report.
# Reset file access times to hide dump's access.
filesystem / /var /export/spool
lock delete
active size 0 report no retries 2
active size 500K report yes retries 1
reset yes
-------End of my original article-------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:50 CDT