Re: [TUHS] Unix filesystem semantics history - files with holes

Re: [TUHS] Unix filesystem semantics history - files with holes

[Richard Tobin]

> 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.

Re: [TUHS] Unix filesystem semantics history - files with holes

[William Corcoran]

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.
> 

Re: [TUHS] Unix filesystem semantics history - files with holes

[Bakul Shah]

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. 

Re: [TUHS] Unix filesystem semantics history - files with holes

[Ronald Natalie]

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>

[TUHS] Unix filesystem semantics history - files with holes

[Erik E. Fair]

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>