Return to BSD News archive
Xref: sserve comp.sys.sun.admin:26077 comp.os.386bsd.bugs:2116
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!sdd.hp.com!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: comp.sys.sun.admin,comp.os.386bsd.bugs
Subject: Re: find goes to NFS disks?
Message-ID: <103946@cup.portal.com>
Date: Wed, 16 Feb 94 10:48:50 PST
Organization: The Portal System (TM)
References: <HSU.94Feb13044616@laphroaig.cs.hut.fi>
Lines: 32
In article <HSU.94Feb13044616@laphroaig.cs.hut.fi>
hsu@cs.hut.fi (Heikki Suonsivu) writes:
| I have this same problem with Sun 3/60 running 4.1.1 and two PCs running
| NetBSD 0.9.
|
| The following command is not supposed to go to NFS mounted disks (It is
| from default root crontab).
|
| find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune
|
| The bad news is, it does. In fact, most sun default cron finds and just
| about all NetBSD daily finds go to NFS disks, when started off root, even
| [...]
The line:
find . \( -fstype nfs -prune \) -o \( -newer $REF_DATE -print \) | \
sort -r > $TAPEDIR/incr$YYMMDDHHMM
is from one of my daily incremental scripts, and it works properly. I first
noticed the NFS "problem" while glancing at the xload windows and wondering
why load averages were > 8 during a backup. The "find" line above fixed the
problem.
And if you ask why I put the find results to a file: it's because I do
daily backups onto QIC tape and the "mt -f /dev/rstN retension" command
is forked-off asynchronously in the backup script and it's possible the
tape may not be back at loadpoint by the time the find has completed; a
simple "while [ ] do ... sleep done" loop takes care of that problem.
Thad Floryan [ thad@btr.com, thad@cup.portal.com, thad@netcom.com ]