All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
To: Dave Chinner <david@fromorbit.com>, Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH v2] fstests: btrfs: Add regression test for reserved space leak.
Date: Wed, 5 Aug 2015 13:04:55 +0900	[thread overview]
Message-ID: <55C18B67.2010300@jp.fujitsu.com> (raw)
In-Reply-To: <20150805031056.GB3902@dastard>

On 2015/08/05 12:10, Dave Chinner wrote:
> On Wed, Aug 05, 2015 at 11:52:36AM +0900, Tsutomu Itoh wrote:
>> On 2015/08/05 10:57, Dave Chinner wrote:
>>> On Wed, Aug 05, 2015 at 09:39:35AM +0800, Qu Wenruo wrote:
>>>> Tsutomu Itoh wrote on 2015/08/05 10:26 +0900:
>>>>> On 2015/08/05 10:08, Qu Wenruo wrote:
>>>>>> +# As the reserved space freeing happens at commit_transaction time,
>>>>>> +# without a transaction commit, no reserved space needs freeing and
>>>>>> +# won't trigger the bug.
>>>>>> +sync
>>>>>
>>>>> Isn't '$BTRFS_UTIL_PROG filesystem sync' better instead of 'sync'?
>>>>>
>>>>> Thanks,
>>>>> Tsutomu
>>>> Hi, Tsutomu-san,
>>>>
>>>> Yes, I did use such method before, but Dave said it's better to use
>>>> unified interface to sync a filesystem other than the specialized
>>>> one.
>>>>
>>>> So I still use sync as Dave said.
>>>
>>> Mainly because "sync" is what users will use to make sure their data
>>> is safe. filesystem specific tools have a habit of doing "special
>>> stuff" to sync a filesystem, so it may not reflect the way users
>>> expect the system to behaviour when they run sync.
>>>
>>> The other option is this:
>>>
>>> _syncfs()
>>> {
>>> 	mntpt=$1
>>>
>>> 	$XFS_IO_PROG -c syncfs $mntpt
>>> }
>>>
>>> _sync_test()
>>> {
>>> 	_syncfs $TEST_DIR
>>> }
>>>
>>> _sync_scratch()
>>> {
>>> 	_syncfs $SCRATCH_MNT
>>> }
>>>
>>> which only runs sync on the filesystem that needs syncing (via the
>>> syncfs() syscall)
>>
>> I think that syncfs is better instead of sync because the syncing of
>> the specified filesystem is necessary.
>
> sync guarantees that. IOWs, there's no difference between sync and
> syncfs for the persepctive of this test and so the test does not
> need really need changing.

I agree that sync and syncfs is not different for this test.

However, sync is syncing of all filesystems, and, syncfs is syncing
of the specified filesystem only.
Therefor, I think that it is better to use sync and syncfs properly
according to the necessity.

Thanks,
Tsutomu



  reply	other threads:[~2015-08-05  4:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  1:08 [PATCH v2] fstests: btrfs: Add regression test for reserved space leak Qu Wenruo
2015-08-05  1:08 ` Qu Wenruo
2015-08-05  1:26 ` Tsutomu Itoh
2015-08-05  1:39   ` Qu Wenruo
2015-08-05  1:39     ` Qu Wenruo
2015-08-05  1:57     ` Dave Chinner
2015-08-05  2:52       ` Tsutomu Itoh
2015-08-05  2:59         ` Qu Wenruo
2015-08-05  2:59           ` Qu Wenruo
2015-08-05  3:10         ` Dave Chinner
2015-08-05  4:04           ` Tsutomu Itoh [this message]
2015-08-05  7:46 ` Filipe David Manana

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=55C18B67.2010300@jp.fujitsu.com \
    --to=t-itoh@jp.fujitsu.com \
    --cc=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.