On Mon, Apr 23, 2012 at 07:29:45PM -0400, Chris Mason wrote:
> On Mon, Apr 23, 2012 at 03:06:41PM -0400, Josef Bacik wrote:
> > We already do the btrfs_wait_ordered_range which will do this for us, so
> > just remove this call so we don't call it twice.  Thanks,
> > 
> > Signed-off-by: Josef Bacik <[email protected]>
> > ---
> >  fs/btrfs/file.c |   11 ++++++-----
> >  1 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> > index f0da02b..0c8ed6a 100644
> > --- a/fs/btrfs/file.c
> > +++ b/fs/btrfs/file.c
> > @@ -1492,14 +1492,15 @@ int btrfs_sync_file(struct file *file, loff_t 
> > start, loff_t end, int datasync)
> >  
> >     trace_btrfs_sync_file(file, datasync);
> >  
> > -   ret = filemap_write_and_wait_range(inode->i_mapping, start, end);
> > -   if (ret)
> > -           return ret;
> >     mutex_lock(&inode->i_mutex);
> 
> Hmmm, I think there are some good benefits to doing the wait
> outside of the mutex.
> 
> The question is, do we need to do it again after we take the mutex?  I
> tend to think no, if you're racing another write with the fsync, you get
> what you deserve.
> 

Yeah I thought about this and I wasn't sure, the only reason I left it where it
was is because of the log_batch thing, I'm not sure what exactly that does and I
didn't want to mess with what we have.  If that can be done outside the mutex
then lets do that.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to