Things to do this week instead of arguing about mixers

[Eric Sandeen]

Jerry James wrote:
> On Mon, Apr 27, 2009 at 2:19 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>> Basically anything that is filled in over time, or filled in sparsely,
>> could potentially benefit.
> 
> I think the word "sparsely" here is confusing me.  This function
> preallocates disk space, right?  So I wouldn't want to use it for a
> file that I expect to be a "sparse file" throughout most or all of its
> lifetime, because then I would be forcing zero-filled blocks onto the
> disk.  Can you explain what you meant by "filled in sparsely"?

Right.  Sorry, that wasn't very specific.  Think of how a torrent file
fills itself in:

1. [a block here]...
2.                                         [a block there]...
3.                   [a little here]...
... etc

and then you end up with
[a block here][hole][a little here][hole][a block there]....

and since the file has holes as it is being completed, I called it "sparse"

Allocators often have a hard time with this kind of behavior, and
telling the fs that you actually want all those blocks allocated right
up front can help get a decent layout.

If you are expecting your file to stay sparse, and you never really plan
to fill it in, then no you probably would not want to preallocate all
that space.

(Just to be clear, by calling the fallocate(); call you don't actually
get "zero-filled blocks on the disk" - you get quickly-allocated blocks
which are marked as uninitialized, for which the filesystem will return
0s until they've been written to.)

-Eric