Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[Chris Mason <chris.mason@oracle.com>]

On Sat, Jun 16, 2007 at 11:31:47AM +0200, Florian D. wrote:
> Chris Mason wrote:
> 
> > Strange, these numbers are not quite what I was expecting ;)  Could you
> > please post your fio job files?  Also, how much ram does the machine
> > have?  Only writing doesn't seem like enough to fill the ram.
> > 
> > -chris
> > 
> > 
> 
> Sure:
> > [global]
> > directory=/mnt/temp/default
> > filename=testfile
> > size=300m
> > randrepeat=1
> > overwrite=1
> > end_fsync=1

[ very bad results on btrfs with these parameters ]

Ok, the numbers make more sense now.  Basically what is happening
is that during the random IO phase, fio is hitting every single block
in the file.  Btrfs will allocate new blocks in a sequential fashion,
but the fsync does writeback in page order.  So, the fsync sees
completely random block ordering, and then we see it again on the reads.

In ext3 even though the writes are random, the fsync uses the original
(sequential) ordering of the blocks, and everything works nicely.

The fix is either delayed allocation or defrag-on-writeback.  Another
option (which I'll have to do for O_SYNC performance) is to leave space
in the blocks allocated to the file for COWs (basically strides of
allocated blocks).

I'll do the defrag-on-writeback right after enospc.

-chris