[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