The Unix Heritage Society mailing list
 help / Atom feed
* [TUHS] Unix filesystem semantics history - files with holes
@ 2019-04-11  2:37 Erik E. Fair
  2019-04-11  5:28 ` Ronald Natalie
  0 siblings, 1 reply; 5+ messages in thread
From: Erik E. Fair @ 2019-04-11  2:37 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

When did the Unix filesystem add the semantics for "files with holes" (large,
sparse files)?

Just an idle question that was sparked by a conversation I had today.

	Erik <fair@clock.org>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] Unix filesystem semantics history - files with holes
  2019-04-11  2:37 [TUHS] Unix filesystem semantics history - files with holes Erik E. Fair
@ 2019-04-11  5:28 ` Ronald Natalie
  0 siblings, 0 replies; 5+ messages in thread
From: Ronald Natalie @ 2019-04-11  5:28 UTC (permalink / raw)
  To: Erik E. Fair; +Cc: The Eunuchs Hysterical Society

Define large?  It appears that filesystems going back to Research V4 supported sparse files.    The maximum file size went up from 2**24 in V6 to 2**32 in V7, and then broke that barrier in several of the subsequent file systems.

> On Apr 10, 2019, at 10:37 PM, Erik E. Fair <fair-tuhs@netbsd.org> wrote:
> 
> When did the Unix filesystem add the semantics for "files with holes" (large,
> sparse files)?
> 
> Just an idle question that was sparked by a conversation I had today.
> 
> 	Erik <fair@clock.org>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] Unix filesystem semantics history - files with holes
@ 2019-04-11 15:57 Richard Tobin
  2019-04-11 19:09 ` William Corcoran
  2019-04-11 19:49 ` Bakul Shah
  0 siblings, 2 replies; 5+ messages in thread
From: Richard Tobin @ 2019-04-11 15:57 UTC (permalink / raw)
  To: Erik E. Fair, The Eunuchs Hysterical Society

> When did the Unix filesystem add the semantics for "files with holes" (large,
> sparse files)?

It was there in the first edition:

https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

The FILE SYSTEM (V) man page includes a last paragraph identical to
that of FILSYS (V) in seventh edition:

  If block b in a file exists, it is not necessary that all blocks
  less than b exist.  A zero block number either in the address words
  of the the i-node or in an indirect block indicates that the
  corresponding block has never been allocated.  Such a missing block
  reads as if it contained all zero words.

The first edition indirect blocks were a bit different though: if the
file was bigger than 8 blocks (4kB), all the blocks in the inode were
(singly) indirect.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] Unix filesystem semantics history - files with holes
  2019-04-11 15:57 Richard Tobin
@ 2019-04-11 19:09 ` William Corcoran
  2019-04-11 19:49 ` Bakul Shah
  1 sibling, 0 replies; 5+ messages in thread
From: William Corcoran @ 2019-04-11 19:09 UTC (permalink / raw)
  To: Richard Tobin; +Cc: The Eunuchs Hysterical Society

Sparse files: “Thin Provisioning” way ahead of its time.  Combined with the patented SUID: The UNIX marvels never cease.  

It just goes to show that all this marketing BS touted today has already been done before.  


Bill Corcoran 

On Apr 11, 2019, at 12:36 PM, Richard Tobin <richard@inf.ed.ac.uk> wrote:

>> When did the Unix filesystem add the semantics for "files with holes" (large,
>> sparse files)?
> 
> It was there in the first edition:
> 
> https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf
> 
> The FILE SYSTEM (V) man page includes a last paragraph identical to
> that of FILSYS (V) in seventh edition:
> 
>  If block b in a file exists, it is not necessary that all blocks
>  less than b exist.  A zero block number either in the address words
>  of the the i-node or in an indirect block indicates that the
>  corresponding block has never been allocated.  Such a missing block
>  reads as if it contained all zero words.
> 
> The first edition indirect blocks were a bit different though: if the
> file was bigger than 8 blocks (4kB), all the blocks in the inode were
> (singly) indirect.
> 
> -- Richard
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] Unix filesystem semantics history - files with holes
  2019-04-11 15:57 Richard Tobin
  2019-04-11 19:09 ` William Corcoran
@ 2019-04-11 19:49 ` Bakul Shah
  1 sibling, 0 replies; 5+ messages in thread
From: Bakul Shah @ 2019-04-11 19:49 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Apr 11, 2019, at 8:57 AM, Richard Tobin <richard@inf.ed.ac.uk> wrote:
> 
>> When did the Unix filesystem add the semantics for "files with holes" (large,
>> sparse files)?
> 
> It was there in the first edition:
> 
> https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

You still had to read all those unallocated blocks as zeroes
if you wanted to copy such a "holey" file. I believe it was
Solaris (may be just for zfs?) that added SEEK_HOLE and
SEEK_DATA lseek whence values.

This could've been hidden if only mmap was allowed on files.
Or alternately read/write buffering was done by the kernel
or the {network,file}-server - which can avoid copying in
cases where it makes sense. 

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-11  2:37 [TUHS] Unix filesystem semantics history - files with holes Erik E. Fair
2019-04-11  5:28 ` Ronald Natalie
2019-04-11 15:57 Richard Tobin
2019-04-11 19:09 ` William Corcoran
2019-04-11 19:49 ` Bakul Shah

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox