*BSD News Article 32039


Return to BSD News archive

Xref: sserve comp.os.386bsd.questions:11103 gnu.misc.discuss:15353
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!gatech!nntp.msstate.edu!emory!cherry.atlanta.com!nntp.mindspring.com!usenet
From: rsanders@mindspring.com (Robert Sanders)
Newsgroups: comp.os.386bsd.questions,gnu.misc.discuss
Subject: Re: Taylor UUCP on FreeBSD???
Date: 25 Jun 1994 14:41:35 GMT
Organization: MindSpring Enterprises, Inc.
Lines: 30
Message-ID: <RSANDERS.94Jun25104138@hrothgar.mindspring.com>
References: <1994Jun13.040754.17764@kosman.uucp>
	<RSANDERS.94Jun22110639@hrothgar.mindspring.com>
	<1994Jun22.184617.10333@cm.cf.ac.uk>
	<RSANDERS.94Jun23005720@hrothgar.mindspring.com>
	<2ugieg$hh9@news.u.washington.edu>
NNTP-Posting-Host: hrothgar.mindspring.com
In-reply-to: tzs@u.washington.edu's message of 25 Jun 1994 06:22:08 GMT

In article <2ugieg$hh9@news.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes:

   Robert Sanders <rsanders@mindspring.com> wrote:
   >   >Linux's shared libc and libm add up to about 280K (they look bigger,
   >   >but they contain holes).  I really couldn't tell you for sure how much
   >	      ^^^^^^^^^^^^ 
   >   Uhh, I don't entirely follow the relevance of that.
   >
   >Well, on a Unix filesystem, if a file has a long run of zeroes that
   >touch both boundaries of one or mor blocks, it may be possible to
   >represent that run of zeroes without actually allocating a block.  In

   That's not what a hole is on a Unix file system.  A hole is a block of
   the file that has never contained data.  A hole is created by seeking
   past the current end of the file and then writing.

That's how you make a hole, but it doesn't explain how one works or
why you would want one.  True, the hole is created by lseek()ing past
the end of the file.  However, from the user's standpoint, that hole
*does* contain data.  It's implicit data, but it's there: any read()s
occurring in extent the hole will return a bunch of zeroes.  There's
no -EHOLE return from a read(), and you definitely don't get -ENODATA.

For files with long runs of zeroes, you can take advantage of the hole
mechanism to save a considerable amount of space: you simply use GNU
cp to copy the file to another file, and move the new file over the
original.  cp will create holes whenver it's possible to represent the
explicit zeroes with "implicit zeroes".

  -- Robert