*BSD News Article 45773


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nexus.coast.net!news.sprintlink.net!news.clark.net!rwatson
From: rwatson@clark.net (Robert Watson)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Suggestion for 2.1
Date: 22 Jun 1995 12:58:10 GMT
Organization: The Star-Lit BBS, Bethesda, Maryland, USA
Lines: 37
Message-ID: <3sbpd2$1s3@clarknet.clark.net>
References: <3r7888$280@germany.eu.net> <3s0ils$7i9@multivac.orthanc.com> <3s3o6h$5k0@bonnie.tcd-dresden.de> <3s7h66$j4l@iii1.iii.net> <3s8qj7$meh@bonnie.tcd-dresden.de> <3saqif$lrc@news.bu.edu>
NNTP-Posting-Host: clark.net
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: TIN [version 1.2 PL2]

Mikhail Teterin (mi@cs.bu.edu) wrote:
: Some time ago (21 Jun 1995 12:00:07 +0200) honorable J Wunsch, 
: residing at j@bonnie.heep.sax.de wrote:
: |It's not a CPU time hog, Peter, but a memory hog.  Waking up every 5
: |or 10 seconds prevents a daemon from being swapped.  Have a few of
: I'm sorry, if I am obviously wrong, but how about some kind of "mounting
: on demand"? Similar to how DOS does it...

The process we were discussin, that woke up every x seconds, was 
originally one to check for mount change requirements.  DOS doesn't 
bother with mounting -- it just reads when yu access the drive letter -- 
and since all mount points under does (X:\) are enforced through the 
operating system (You can't put it anywhere else without a TSR that 
modifies the file interface, and that would be messy as you'd never know 
which programs are going to use your routines, and which won't.. I think 
append does this, but I personally would try to avoid append) -- since 
Unix doesn't know where you would put the mount,and because file access 
occurs pretty requently all over the place, it wouldn't neccesarily be a 
good idea to check a device every time a directory was accessed.  It also 
wouldn't be consistent with the UFS file system -- having stuff randomly 
disappear without an unmount is bad.  Actually, I guess that's the key 
problem with mounting on directory access--when should the systemm 
unmount, and what happens if the disk radnomly disappears or is replaced?

Acually -- it is possible to tell if the disk has been removed/change d-- 
I believe Microsoft (Symantec?) used it in MS BAckup -- the drive light 
stays on and backup can tell when you've put the new disk in.  Of course, 
they run a compatibility test firstt that apparently fails on some 
machines..  And having the drive light always on is disconcerting in 
terms of the purpose of a drive light -- telling when yuo shoudn't remove 
the disk ;).  That's one features I've always liked about macs (and 
non-caddy CD-ROMs) -- the ability to detect a disk insert/eject.

--
Robert Watson   rwatson@sidwell.edu   http://www.sidwell.edu/~rwatson/
The goal of science is to build better mousetraps.  The goal of nature
is to build better mice.