[Btrfs-devel] [RFC] fsync patch take 5?
Chris Mason
chris.mason at oracle.com
Fri Aug 10 10:44:41 PDT 2007
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
More information about the Btrfs-devel
mailing list