[Btrfs-devel] [RFC] fsync patch take 5?

[Chris Mason]

On Fri, 10 Aug 2007 13:34:00 -0400
Josef Bacik <jwhiter at redhat.com> wrote:

> On Fri, Aug 10, 2007 at 01:20:27PM -0400, Chris Mason wrote:
> > On Fri, 10 Aug 2007 11:58:45 -0400
> > Josef Bacik <jwhiter at redhat.com> wrote:
> > 
> > > Hello,
> > > 
> > > Ok here's the new patch, all tested and pretty with the
> > > suggestions you made yesterday.  As always, let me know if you
> > > need me to change anything.  If there are no objections I'll move
> > > on to fixing block accounting.  Thank you,
> > > 
> > 
> > It looks good to me, I'll give it a spin here as well.  One
> > question:
> > 
> > >  	mutex_lock(&root->fs_info->fs_mutex);
> > > +	if (!BTRFS_I(inode)->last_trans)
> > > +		goto out;
> > > +	mutex_lock(&root->fs_info->trans_mutex);
> > > +	if (BTRFS_I(inode)->last_trans <=
> > > +	    root->fs_info->last_trans_committed) {
> > > +		BTRFS_I(inode)->last_trans = 0;
> > 
> > Why do we set last_trans to zero if we're about to commit?  If
> > someone comes in and does a second fsync, we want to keep the
> > last_trans recorded so the optimization can continue, right?
> > 
> 
> We set it to 0 if the commit has already occurred, so if somebody
> comes right behind us the first if statement sees that we don't need
> to force a commit and we can exit without grabbing the trans_mutex,
> so it should be faster.  Thanks,

Aha, good point ;)

-chris