From: Josef Bacik <jbacik@fb.com>
To: <miaox@cn.fujitsu.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH V2 3/4] Btrfs: don't mix the ordered extents of all files together during logging the inodes
Date: Wed, 29 Jan 2014 13:48:02 -0500 [thread overview]
Message-ID: <52E94CE2.7030500@fb.com> (raw)
In-Reply-To: <52E865FB.9050300@cn.fujitsu.com>
On 01/28/2014 09:22 PM, Miao Xie wrote:
> On Tue, 28 Jan 2014 09:55:58 -0500, Josef Bacik wrote:
>> On 01/14/2014 07:31 AM, Miao Xie wrote:
>>> There was a problem in the old code:
>>> If we failed to log the csum, we would free all the ordered extents in the log list
>>> including those ordered extents that were logged successfully, it would make the
>>> log committer not to wait for the completion of the ordered extents.
>>>
>>> This patch doesn't insert the ordered extents that is about to be logged into
>>> a global list, instead, we insert them into a local list. If we log the ordered
>>> extents successfully, we splice them with the global list, or we will throw them
>>> away, then do full sync. It can also reduce the lock contention and the traverse
>>> time of list.
>>>
>> If we fail to log the csums we'll return an error and commit the transaction so it doesn't matter that we free all the ordered extents, everything will be waited on properly. Thanks,
>
> No. Maybe my explanation is not clear. Please consider the following case:
>
> Task1 (sync file1) Task2 (sync file2)
> btrfs_sync_file()
> btrfs_sync_file()
> start_log_trans()
> start_log_trans()
> btrfs_get_logged_extents()
> btrfs_log_changed_extents()
> btrfs_get_logged_extents()
> btrfs_log_changed_extents() failed
> btrfs_free_logged_extents()
> this function will free all logged extents
> including the ones that are inserted by task1
> btrfs_end_log_trans()
> btrfs_sync_log()
> btrfs_wait_logged_extents()
> but no extents to be
> waited
> sync end
> btrfs_wait_ordered_extents()
> but this operation just wait for file2's
> extents that is in the specified range.
> btrfs_commit_transaction()
> the committer also doesn't wait for the extents
> of file1
>
Ah I see then yes that's correct. I'll pull it in, thanks,
Josef
next prev parent reply other threads:[~2014-01-29 18:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 12:31 [PATCH V2 0/4] Btrfs: improve the performance fluctuating of the fsync Miao Xie
2014-01-14 12:31 ` [PATCH V2 1/4] Btrfs: filter the ordered extents that has been logged Miao Xie
2014-01-28 14:50 ` Josef Bacik
2014-01-29 2:08 ` Miao Xie
2014-01-14 12:31 ` [PATCH V2 2/4] Btrfs: don't get the lock when adding a csum into a ordered extent Miao Xie
2014-01-28 16:00 ` Josef Bacik
2014-01-29 2:25 ` Miao Xie
2014-01-29 18:43 ` Josef Bacik
2014-01-14 12:31 ` [PATCH V2 3/4] Btrfs: don't mix the ordered extents of all files together during logging the inodes Miao Xie
2014-01-28 14:55 ` Josef Bacik
2014-01-29 2:22 ` Miao Xie
2014-01-29 18:48 ` Josef Bacik [this message]
2014-01-14 12:31 ` [PATCH V2 4/4] Btrfs: flush the dirty pages of the ordered extent aggressively during logging csum Miao Xie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E94CE2.7030500@fb.com \
--to=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).