From: Stefan Behrens <sbehrens@giantdisaster.de>
To: Shilong Wang <wangshilong1991@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: fix race condition between writting and scrubing supers
Date: Sat, 19 Oct 2013 16:03:57 +0200 [thread overview]
Message-ID: <5262914D.7030306@giantdisaster.de> (raw)
In-Reply-To: <CAP9B-Qncw5aCJzbQapy6i4iRrJ-mYh_yhkorY7+p9wZtzJodTQ@mail.gmail.com>
On 10/19/2013 12:32, Shilong Wang wrote:
> 2013/10/19, Stefan Behrens <sbehrens@giantdisaster.de>:
>> On 10/19/2013 06:17, Wang Shilong wrote:
>>> From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>>>
>>> Scrubing supers is not in a transaction context, when trying to
>>> write supers to disk, we should check if we are trying to
>>> scrub supers.Fix it.
>>>
>>> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
>>> ---
>>> fs/btrfs/disk-io.c | 2 ++
>>> fs/btrfs/transaction.c | 2 ++
>>> 2 files changed, 4 insertions(+)
>>>
>>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>>> index 419968e..0debb19 100644
>>> --- a/fs/btrfs/disk-io.c
>>> +++ b/fs/btrfs/disk-io.c
>>> @@ -3582,7 +3582,9 @@ int btrfs_commit_super(struct btrfs_root *root)
>>> return ret;
>>> }
>>>
>>> + btrfs_scrub_pause_super(root);
>>> ret = write_ctree_super(NULL, root, 0);
>>> + btrfs_scrub_continue_super(root);
>>> return ret;
>>> }
>>>
>>> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
>>> index 277fe81..3ebcbbd 100644
>>> --- a/fs/btrfs/transaction.c
>>> +++ b/fs/btrfs/transaction.c
>>> @@ -1892,7 +1892,9 @@ int btrfs_commit_transaction(struct
>>> btrfs_trans_handle *trans,
>>> goto cleanup_transaction;
>>> }
>>>
>>> + btrfs_scrub_pause_super(root);
>>> ret = write_ctree_super(trans, root, 0);
>>> + btrfs_scrub_continue_super(root);
>>> if (ret) {
>>> mutex_unlock(&root->fs_info->tree_log_mutex);
>>> goto cleanup_transaction;
>>>
>>
>> What kind of race do you see between writing the 4K superblock and scrub
>> checking its checksum? Or in other words, what could happen?
> Yeah, it did not hurt. but it may output checksum mismatch. For
example:
> Writing 4k superblock is not totally finished, but we are trying to
scrub it.
Have you ever seen this issue?
If yes, let's find a different solution. You scrub, let's say, once a
week. Scrubbing the superblock takes, let's say, 100ms, then it's
finished. This short race doesn't justify to add such code to
btrfs_commit_transaction and btrfs_commit_super IMHO. And commiting a
transaction is synchronized to scrub already when the commit root is
updated.
If this is really an issue and these 4K disk writes and reads interfere,
let's find a better solution please.
next prev parent reply other threads:[~2013-10-19 14:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-19 4:17 [PATCH] Btrfs: fix race condition between writting and scrubing supers Wang Shilong
2013-10-19 8:50 ` Stefan Behrens
2013-10-19 10:32 ` Shilong Wang
2013-10-19 14:03 ` Stefan Behrens [this message]
2013-10-19 14:34 ` Wang Shilong
2013-10-20 4:03 ` Wang Shilong
2013-10-22 8:37 ` Stefan Behrens
2013-10-22 16:55 ` Bob Marley
2013-10-23 17:21 ` Stefan Behrens
2013-10-24 10:08 ` Chris Mason
2013-10-24 10:42 ` Miao Xie
2013-10-24 11:32 ` Wang Shilong
2013-10-25 2:14 ` Miao Xie
2013-10-20 7:28 ` Bob Marley
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=5262914D.7030306@giantdisaster.de \
--to=sbehrens@giantdisaster.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=wangshilong1991@gmail.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).