How do you find the symbolic links to files.

[Bob Goudreau]

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