shanega@athena.mit.edu (Shane G. Artis) (02/12/91)
Hi, I read earlier in this group that someone with a Cube, OD, and version 2.0 of the software noticed that, when an OD was mounted, sometimes it would begin to perform huge amounts of activity, reading and spinning, and the OD could no longer be dismounted. This is NOT due to a problem with the optical disk drive, and is, in fact, normal behavior (though undesirable). I had the same problem on my '030 cube and traced it to a daily administration task which searches (using 'find') for files suffixed '.nfs' and clears them. It should (I think) search just the boot disk, but unfortunately it also searches the mounted optical disk. If you are a standalone system, I recommend logging in as root and removing the last line of the /usr/adm/daily file (make a backup of course). This is the source of the problem. This is just a quick and dirty fix, and may cause problems on networked machines. Talk to your administrator. Anyone have a real fix - i.e., does 'find' have an option that prevents recursive searches of mounted file systems or some such thing? Shane
scott@erick.gac.edu (Scott Hess) (02/12/91)
In article <1991Feb11.201046.12640@athena.mit.edu> shanega@athena.mit.edu (Shane G. Artis) writes:
and the OD could no longer be dismounted. This is NOT due to a problem
with the optical disk drive, and is, in fact, normal behavior (though
undesirable). I had the same problem on my '030 cube and traced it to
a daily administration task which searches (using 'find') for files
suffixed '.nfs' and clears them. It should (I think) search just the
boot disk, but unfortunately it also searches the mounted optical disk.
If you are a standalone system, I recommend logging in as root and
removing the last line of the /usr/adm/daily file (make a backup
of course). This is the source of the problem.
This is correct. The script only executes at about 2am, though, or
at least when it's executed in my experience.
[Story - this summer, one of my roomates and I were in working late at
night, this in a building with lots of NeXTs (well, it was actually
at NeXT, but that's incidental). We're working along, working along,
then at 2am our machines go berserk. This was quite noticable, as
we both had two machines in "our" offices, and there were of course
many machines up and down the way. Scary! ]
Anyhow, rather than delete that line in the /usr/adm/daily file, comment
it out by inserting a '#' character at the beginning of it. Also, you
might want to put a little remark (again commented by # signs) to
indicate why you did this, in case you later need to revert (and are
no longer sure exactly what happened).
Another option would be to move the line to /usr/adm/weekly. That would
cut execution to once a week.
This is just a quick and dirty fix, and may cause problems on networked
machines. Talk to your administrator. Anyone have a real fix - i.e.,
does 'find' have an option that prevents recursive searches of mounted
file systems or some such thing?
Well, I suppose that could be done. I'm not sure how. The script itself
uses '-fstype nfs -prune' to stop searches at nfs mount-points. The
-xdev option is supposed to cause find not to traverse to a filesystem
different from the one on which the current argument resides. Maybe:
find / -xdev -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune
would be better (tell me if this works!).
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Tried anarchy, once. Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."