Sparse Files ?

[Guy Harris]

>Hummm - this sounds a bit like CP/M - obviously UNIX stuffs a lot more info
>into the inode than CP/M does into it's directory slot, but the method of
>a list of block numbers is exactly the same. Now for the $64000 question:
>what does UNIX do when it runs out of block number slots in the inode. I
>doubt it's the same as CP/M (which just allocates a second directory entry
>for the file, and sets a flag to show this is an extension). So how does
>UNIX handle very big files?

In the most common UNIX file systems, namely the V7 one (used by 4.1BSD,
System III, and System V, as well as V7 itself, and derivatives of the
aforementioned systems) and the 4.2BSD one, the first N (N == 10 for V7, N
== 12 for 4.2BSD) slots are "direct" pointers; they contain the block
number of a block in the file (the zeroth one contains the block number
of the zeroth block, etc.).  The N+1st one is an "indirect" pointer; it
contains the block number of a block full of block numbers in the file,
starting with the N+1st block of the file.  The N+2nd one is a
"doubly-indirect" pointer; it contains the block number of a block full
of block numbers of indirect blocks, and the N+3rd one is a
"triply-indirect" block, containing just what you think it would.

An block in the V7 file system is usually either 512 or 1024 bytes, and
a block number is 4 bytes; a block in the 4.2BSD file system is
typically 4K or 8K.  Some versions of both file system can have even
bigger blocks.  Thus, if it runs out of block number slots in the inode,
given that the last slot maps a block full of blocks that map blocks
full of..., your file has gotten pretty big; the V7 and 4.2BSD file
systems just say "enough is enough" and don't let your file get any
bigger.