Subject: Re: ffs_valloc: dup alloc
To: David Laight <david@l8s.co.uk>
From: Robert Elz <kre@munnari.OZ.AU>
List: port-i386
Date: 02/28/2002 02:19:32
    Date:        Tue, 26 Feb 2002 13:12:32 +0000
    From:        David Laight <david@l8s.co.uk>
    Message-ID:  <20020226131232.B27823@snowdrop.l8s.co.uk>

  | There are 96 slots (presumably in the inode) that will reference 1k frags.

There are 12 direct block pointers, the last used of which may contain a frag
instead of a full block.  All the others contain only full sized blocks.

  | Beyond that all allocations seem to be in 8k blocks.

In units of the filesystem blocksize (which is commonly 8K)

  | First indirection 8k buffer - 2k blocks of 8k each.

daddr_t is 4 bytes, so blksize/4 is the number of pointers in any
indirect block.

A double indirect block can reference to (blksize^3)/16 (+ change) bytes.
For a 16K block size, that's 250 GB +

But since files can contain holes, and these days file sizes are measured
in 64 bits, there's no real way that's plausible to avoid triple
indirect blocks.   Even a block size of a MB would be nowhere near large
enough (2^64 is a big big number).   8 MB blocks would do it, but
thath means 1 MB frags (minimum), which means 1MB allocated for the smallest
non-zero file (apart from the drive usage, which may almost be cheap enough,
consider the ram usage when 1MB needs to be allocated to read the smallest
file from disc).   Even if you want to try it, don't bet upon it being 
supported.

In other words, there's no way to work around a bug if there is one, just
find and fix it.

kre