[Btrfs-devel] [RFC] All my fsync changes

Chris Mason chris.mason at oracle.com
Thu Aug 9 16:49:10 PDT 2007


On Thu, 9 Aug 2007 17:56:18 -0400
Josef Bacik <jwhiter at redhat.com> wrote:

> Hello,
> 
> Ok here are all my fsync changes, including the fix for the
> put_transaction stuff that I posted earlier.  I figure it'll be
> easier to just commit it as one thing then each individual peice.
> The additional thing that I did was add a radix tree that tracks the
> current outstanding transactions.  I also added a field to the in
> memory btrfs inode that keeps track of the last transaction that
> modified the inode.  So when we go to do a fsync on the inode if the
> commit was already done or the transaction was removed (meaning it
> had been committed and freed) we just exit out.  So here are the
> numbers. This is running fs_mark with the following command
> 
> fs_mark -d /mnt/btrfs-test/default/ -s 10240 -n 1000
> 
> run 10 times.  First run is without any of the patches, with the
> exception of the put_transaction/trans_mutex fix.
> 
> AVG: 61 files/sec
> 
> And this is the numbers with the patch thats attached to this email
> 
> 
> AVG: 94.32 files/sec

Great, although I'm a little surprised it helps so much for a single
thread case.

> 
> Now I'm kind of uncertain about how I track the last_trans for the
> inode, I think its right but I'm not entirely sure, so if I need to
> be doing this elsewhere please let me know.  Thanks much,

This code really looks correct, one change I would suggest is that
since the transactions are put down in order, we don't have to worry
about maintaining the radix tree.  You know that if transid Y is on
disk, then transid Y-1 and Y-2 etc are also on disk.

So, you can just record the most recent transid to hit the disk and
compare it with the id you store in the inode, forcing a commit if
your transaction isn't on disk yet. Did you need the radix tree for
something else?

-chris



More information about the Btrfs-devel mailing list