[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