Path: utzoo!attcan!uunet!midway!ncar!gatech!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Trojan Horses
Message-ID: <12402:Oct2605:19:2790@kramden.acf.nyu.edu>
Date: 26 Oct 90 05:19:27 GMT
References: <1990Oct18.121818.9956@athena.mit.edu> <35111@cup.portal.com> <18619@rpp386.cactus.org>
Organization: IR
Lines: 28

In article <18619@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
> In article <35111@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
> >This sounds like very bad file system design.  If you are over some quota,
> >the write() that caused you to go over the quota should return an error.
> >The local system should determine your quota and remaining space and
> >check this on each write.
> you have just required that all write() operations be performed
> synchronously.

Not at all. It doesn't even require that the server hear about the
operation, because clients can be given ``windows'' upon the disk space.
``Here, you can assume you have at least 5M until I tell you
otherwise.''

> there are open flags defined to support synchronous
> i/o - use them, or tell your vendor to include them in your version
> of the o/s, but don't hobble applications that aren't as serious
> about their output as yours.

What several participants in this discussion seem to be missing is that
EDQUOT is *not* as disastrous as EIO and should *not* require such
drastic measures as fsync()/O_SYNC. If the CPU and disks are perfectly
reliable, then why should such synchronization be required? To put it
differently, why can't an application be reliable under quota errors
without going to all the real work necessary for general reliability?
EDQUOT is a relatively ``normal'' condition compared to EIO.

---Dan