Things to do this week instead of arguing about mixers

[Michael Cronenworth]

-------- Original Message --------
Subject: Re: Things to do this week instead of arguing about mixers
From: Eric Sandeen <sandeen at redhat.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 04/27/2009 03:53 PM

> 
> Try downloading a large (multi-gigabyte) torrent on ext4 or xfs or
> btrfs; see what the resulting file layout looks like if your client does
> not preallocate.  Now use a client that preallocates the space and try
> again.  Calling fallocate() first for the full file size will help on
> all these filesystems (well, TBH, I have not tested it on btrfs).
> 
> If there are well-defined interfaces to give hints to the filesystem
> about the ultimate state of a file, it's a nice feature, not a bug.
> 
> Sure, filesystems should do the best they can in the absence of hints,
> but performing well (or better) _with_ a hint is not indicative of a bug.
> 

I can truely only speak for XFS, but btrfs might be similar:

XFS waits[1] to allocate space for a few seconds in order to see the 
full file size of the write() you want to commit. This allows for a more 
complete allocation at the cost of data integrity.

deluge, one bittorrent client, gives you the option of full or dynamic 
allocation. I download multi-gigabyte torrents often with deluge and 
full allocation.

In the end -- SSDs should be cheaper so this discussion is moot.

[1] http://en.wikipedia.org/wiki/Xfs#Delayed_allocation