Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.unix.wizards
Subject: Re: What new system calls do you want in BSD?
Message-ID: <19451@nuchat.UUCP>
Date: 11 Feb 90 19:09:55 GMT
References: <12157@stealth.acf.nyu.edu> <1990Jan24.193433.3332@semi.harris-atd.com> <23449@stealth.acf.nyu.edu> <1990Feb8.080645.4458@semi.harris-atd.com> <5068.16:48:52@stealth.acf.nyu.edu> <1990Feb9.025853.8202@semi.harris-atd.com>
Reply-To: steve@nuchat.UUCP (Steve Nuchia)
Distribution: usa
Organization: Houston Public Access
Lines: 26

In article <1990Feb9.025853.8202@semi.harris-atd.com> del@thrush.semi.harris-atd.com (Don Lewis) writes:
>If the filesystem is mounted read-only, the atime doesn't get updated, is
>this a security violation?

Hmm... maybe we don't need a new sys call, or a new argument/flag for
old ones, to let backup avoid updating the inode.  Maybe we just need
to remove an arbitrary restriction on an old one.  Namely, allow devices
to be mounted more than once.  If the second mount is RO then you
can back up from it and get most of what you want.

While I'm on the subject, a thought on disk/partition/file system
organization:

The current situation is really a mess, with all the partitioning
and defect mapping burried down in *each* disk driver.  What we
need is truly raw drivers for specific hardware and a generic
indirect driver implementing "cooked" features -- mapping,
partitioning, striping, mirroring -- in a *standard* way.

Neither of these suggestions is particularly difficult, unless
I missed something when I last looked at the relevant code.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"If the conjecture `You would rather I had not disturbed you
 by sending you this.' is correct, you may add it to the list of
 uncomfortable truths."   - Edsgar Dijkstra