[Btrfs-devel] btrfs timeline - fragmentation and delayed allocation

[Chris Mason]

On Thu, 20 Dec 2007 11:35:22 +0600
sftf <sftf-misc at mail.ru> wrote:

> CM> Hi,
> 
> CM> Btrfs supports delayed allocation already, its the main method
> CM> for file IO.  It is currently possible to do online defrag of the
> CM> Btree and of files.
> 
> CM> We don't yet have very good fragmentation analysis tools.
> 
> CM> -chris
> 
> That's good!
> And two more questions, please::
> - what degree (very low, low, medium or hight) of a fragmentation we
> can expect from btrfs (now, in future)?

This will depend on the usage.  The copy on write nature of things
makes Btrfs more likely to fragment than other linux filesystems, but
there will be a number of allocator features meant to prevent this.

Also, the ability to defrag on the fly will make it easy to fix
fragmentation.

> - how (meta)data's safety and integrity affected by btrfs's delayed
> allocation in case OS/hardware crash?
> 

There are two answers for this.  Since data=ordered is not yet
implemented, it is currently possible to get null bytes in a file after
a crash because the metadata may get to disk before the data does.

Over the long term, delayed allocation won't affect safety or integrity.

-chris