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

Josef Bacik jwhiter at redhat.com
Fri Aug 10 10:34:00 PDT 2007


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,

Josef



More information about the Btrfs-devel mailing list