From: janet@cs.uwa.oz.au (Janet Jackson)
Subject: Help! Copilot dump leaving active filesys permanently locked
Summary: root (still) can't unlock FS after Backup Copilot dump
Keywords: Backup Copilot, dump, lockfs
Organization: Dept. Computer Science, University of Western Australia.
Date: Fri, 9 Oct 1992 06:25:51 GMT

A while ago I asked about a problem with Backup Copilot dump leaving
filesystems locked, such that even root can't unlock them and the
only remedy is to reboot.

I was advised to install some patches (100483-02 - NFS Jumbo;
100518-01 - lockd; and 100551-02 - Backup Copilot Jumbo) and they seemed
to fix it on my test system.  So last night I ran it live on our network
of 27 Sun4s and Sparcstations, to do level 9 dumps of our 31 "people"
filesystems.  All the filesystems were dumped properly to tape and can be
restored from.  I checked them all.

However, the abovementioned locking problem occurred on 5 of the filesystems.

Here's the tail end of dump's output on one of these:

    DUMP: 13198 blocks (6.44MB) on 1 volume
    DUMP: DUMP IS DONE
    DUMP: cannot lock file system: Not owner

Then, running "lockfs" on the filesystem's host gets you:

   Filesystem           Locktype   Comment
   /home/bison          write      dump[21626]: Fri Oct  9 01:39:38 1992

Running "lockfs -a -u" as root on that host gets you:

   /home/bison: Not owner

and the filesystems remain locked.  Rebooting seems to be the only way
out of it - not a good workaround when you've got users running week-long
jobs.

All the systems have lockfsintr turned on.

I have /etc/dump.conf set up to put write locks on all the filesystems
that were dumped last night.  I'll quote my /etc/dump.conf below for
your reference.

It seems to me that the filesystems that got locked up were the active ones,
ie those on which users would have been actively trying to write at the
time of the backup.  All the filesystems that would have been largely
quiescent worked fine.  The only active filesystem that did work OK is on
our one SunOS4.1.2 host.  All our other systems are 4.1.1.

The weird thing is that apart from being unable to unlock the filesystem,
dump seems to work fine.  It does return a non-zero exit status.


So what on earth am I doing wrong?  I'll be grateful for *any* information.
Some of you do have Backup Copilot working, don't you?  (Maybe you don't
have users on while the backups are going.)  PLEASE REPLY BY EMAIL AND I'LL
SUMMARISE.

Below is my /etc/dump.conf.  Note that all the filesystems dumped last night
would have been covered by the "default" specification.

Janet Jackson
<janet@cs.uwa.edu.au>
Systems Administrator
Department of Computer Science
The University of Western Australia

--->cut here<---
# /etc/dump.conf for Backup Copilot dump
# Janet Jackson <janet@cs.uwa.edu.au>, 1992-10-07
# This file is used on all Suns at UWA Computer Science.
# The master copy is kept in ~backup/Copilot/dump.conf.
# ONLY CHANGE THE MASTER COPY.
#
# Version 1 - initial plug-in of Copilot dump to existing setup.
# Do lots of locking and retrying for now - see how this affects the users.

# 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.  Used for most 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
Newsgroups: comp.sys.sun.admin