Warning: Failed mail to VMS host

[mail-support%cernvax.cern.ch at pucc.princeton.edu]

Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at 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 <goudreau at larrybud.rtp.dg.com>
Subject: Re: How do you find the symbolic links to files.
Date: 10 Dec 90 22:53:27 GMT
Sender: Usenet Administration <usenet at dg-rtp.dg.com>
To:       unix-wizards at sem.brl.mil

In article <2707:Dec1001:26:4290 at kramden.acf.nyu.edu>,
 brnstnd at 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 at dg-rtp.dg.com
62 Alexander Drive			...!mcnc!rti!xyzzy!goudreau
Research Triangle Park, NC  27709, USA

-----------------------------

From: Dan Bernstein <brnstnd at kramden.acf.nyu.edu>
Subject: Re: How do you find the symbolic links to files.
Date: 12 Dec 90 02:37:20 GMT
To:       unix-wizards at sem.brl.mil

In article <1990Dec10.191522.2757 at erg.sri.com> zwicky at erg.sri.com (Elizabeth
 Zwicky) writes:
> In article <2469:Dec1001:13:4390 at kramden.acf.nyu.edu>
 brnstnd at 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 at erg.sri.com>. And who agreed in a
later article with Tom's conclusions. But this is besides the point.