Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!adm!news From: mail-support%cernvax.cern.ch@pucc.princeton.edu Newsgroups: comp.unix.internals Subject: Warning: Failed mail to VMS host Message-ID: <25265@adm.brl.mil> Date: 14 Dec 90 05:00:21 GMT Sender: news@adm.brl.mil Lines: 117 Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN@CERNVAX.BITNET> could not be delivered. The error message was: Deferred: %MAIL-E-OPENOUT, error openning as output This message is equivalent to the DECnet-VAX error message: -SYSTEM-F-EXDISKQUOTA, disk quota exceeded The reason why your message could not be delivered is caused by the fact that your correspondants account has ran out of diskquota. Please contact your correspondant (by phone or otherwise) and tell him about this problem. ====== The start of Your original message ====== UNIX-WIZARDS Digest Wed, 12 Dec 1990 V11#059 Today's Topics: Re: How do you find the symbolic links to files. Re: non-superuser chown(2)s considered harmful Re: Preventing date rollback Re: Unix files should have both real and effective ids for files too Complex security mechanism is unsecure (was Re: non-superuser chown(2)s considered harmful) Re: Interfaces for accessing kernel memory UNIX ACLs (was: Re: non-superuser chown(2)s considered harmful) Re: The performance implications of the ISA bus Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6 Remote Command Execution over WAN. NL -> CR NL through sockets HOW TO ACCESS PROCESS INFORMATION??? fun things mapped into user space Shared memory (shm) - a safe way to pick ids? How to get past end of cpio archive on tape ----------------------------------------------------------------- From: Bob Goudreau Subject: Re: How do you find the symbolic links to files. Date: 10 Dec 90 22:53:27 GMT Sender: Usenet Administration To: unix-wizards@sem.brl.mil In article <2707:Dec1001:26:4290@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > Sorry. What I meant was that the archiver can just squish the first N > zero-filled blocks it finds into holes. Then it writes zeros into the > remaining zero-filled blocks. OK. I understand your point now. > > The only portable way is to examine the file data looking for > > stretches of nulls; but as I mentioned, this makes your program slower > > than it has to be. > > Yes, it makes it slower. It does not make it significantly slower. I guess it depends on how many holey files you have, and how big their holes are. Most of the read()s over the holes sould come fairly cheap, but you now also have the additional step of examining the input data looking for stretches of zeros. > > > > Unfortunately, while such > > > > an approach is portable, its performance will leave something to be > > > > desired on files with truly tremendous holes in them; much time will > > > > be wasted on read()ing the holes. > > > No, there won't be any read() time wasted. There will be CPU time > > > wasted. (Tom points out in another article that vectorization helps > > > here.) > > Yes, there will be read() time wasted; the archiver must read() the > > entire file a chunk at a time and then check each chunk for zeros. > > It has to read the entire file anyway, if it is going to write() it onto > tape. Where are your extra read()s? No, my point is that dump(1M) *doesn't* have to read() the entire file; by examining the file system directly, it can determine in advance exactly where the holes are and thus avoid read()ing through them. The only data it need read are the actual allocated data blocks. Whereas the more portable & straightforward archiving approach must naively read() through (say) a gigabyte of hole, and also analyze all the null bytes thus read in order to verify that they indeed form a hole. ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau Research Triangle Park, NC 27709, USA ----------------------------- From: Dan Bernstein Subject: Re: How do you find the symbolic links to files. Date: 12 Dec 90 02:37:20 GMT To: unix-wizards@sem.brl.mil In article <1990Dec10.191522.2757@erg.sri.com> zwicky@erg.sri.com (Elizabeth Zwicky) writes: > In article <2469:Dec1001:13:4390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Elizabeth said that ``you have to get pretty intimate with the disk'' to > >tell that a file has holes, or something like that. She concluded that > >an archiver can with good conscience restore files with as many holes as > >possible, hence saving as much space as possible. > No, actually, Elizabeth didn't say either of those things. Well, sorry, I thought it was Elizabeth who said ``you have to get pretty intimate with the disk to tell that the 20 meg of nulls aren't there'' in <1990Dec5.052124.28435@erg.sri.com>. And who agreed in a later article with Tom's conclusions. But this is besides the point.