All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Rohner <andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
To: Ryusuke Konishi
	<konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 1/1] nilfs2: add missing blkdev_issue_flush() to nilfs_sync_fs()
Date: Mon, 01 Sep 2014 21:18:30 +0200	[thread overview]
Message-ID: <5404C686.4070800@gmx.net> (raw)
In-Reply-To: <5404BE5C.9080302-hi6Y0CQ0nG0@public.gmane.org>

On 2014-09-01 20:43, Andreas Rohner wrote:
> Hi Ryusuke,
> On 2014-09-01 19:59, Ryusuke Konishi wrote:
>> On Sun, 31 Aug 2014 17:47:13 +0200, Andreas Rohner wrote:
>>> Under normal circumstances nilfs_sync_fs() writes out the super block,
>>> which causes a flush of the underlying block device. But this depends on
>>> the THE_NILFS_SB_DIRTY flag, which is only set if the pointer to the
>>> last segment crosses a segment boundary. So if only a small amount of
>>> data is written before the call to nilfs_sync_fs(), no flush of the
>>> block device occurs.
>>>
>>> In the above case an additional call to blkdev_issue_flush() is needed.
>>> To prevent unnecessary overhead, the new flag THE_NILFS_FLUSHED is
>>> introduced, which is cleared whenever new logs are written and set
>>> whenever the block device is flushed.
>>>
>>> Signed-off-by: Andreas Rohner <andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
>>
>> The patch looks good to me except that I feel the use of atomic
>> test-and-set bitwise operations something unfavorable (though it's
>> logically correct).  I will try to send this to upstream as is unless
>> a comment comes to mind.
> 
> I originally thought, that it is necessary to do it atomically to avoid
> a race condition, but I am not so sure about that any more. I think the
> only case we have to avoid is, to call set_nilfs_flushed() after
> blkdev_issue_flush(), because this could race with the
> clear_nilfs_flushed() from the segment construction. So this should also
> work:
> 
>  +	if (wait && !err && nilfs_test_opt(nilfs, BARRIER) &&
>  +	    !nilfs_flushed(nilfs)) {
>  +              set_nilfs_flushed(nilfs);
>  +		err = blkdev_issue_flush(sb->s_bdev, GFP_KERNEL, NULL);
>  +		if (err != -EIO)
>  +			err = 0;
>  +	}
>  +

On the other hand, it says in the comments to set_bit(), that it can be
reordered on architectures other than x86. test_and_set_bit() implies a
memory barrier on all architectures. But I don't think the processor
would reorder set_nilfs_flushed() after the external function call to
blkdev_issue_flush(), would it?

/**
 * set_bit - Atomically set a bit in memory
 * @nr: the bit to set
 * @addr: the address to start counting from
 *
 * This function is atomic and may not be reordered.  See __set_bit()
 * if you do not require the atomic guarantees.
 *
 * Note: there are no guarantees that this function will not be reordered
 * on non x86 architectures, so if you are writing portable code,
 * make sure not to rely on its reordering guarantees.
 */

br,
Andreas Rohner
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-09-01 19:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-31 15:47 [PATCH v2 0/1] nilfs2: add missing blkdev_issue_flush() to nilfs_sync_fs() Andreas Rohner
     [not found] ` <1409500033-30791-1-git-send-email-andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
2014-08-31 15:47   ` [PATCH v2 1/1] " Andreas Rohner
     [not found]     ` <1409500033-30791-2-git-send-email-andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
2014-09-01 17:59       ` Ryusuke Konishi
     [not found]         ` <20140902.025939.1812841141168890644.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2014-09-01 18:43           ` Andreas Rohner
     [not found]             ` <5404BE5C.9080302-hi6Y0CQ0nG0@public.gmane.org>
2014-09-01 19:18               ` Andreas Rohner [this message]
     [not found]                 ` <5404C686.4070800-hi6Y0CQ0nG0@public.gmane.org>
2014-09-03  0:35                   ` Ryusuke Konishi
     [not found]                     ` <20140903.093525.810247375407684014.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2014-09-03 12:32                       ` Andreas Rohner
     [not found]                         ` <54070A56.9050807-hi6Y0CQ0nG0@public.gmane.org>
2014-09-07  5:12                           ` Ryusuke Konishi
     [not found]                             ` <20140907.141232.2124135104047617747.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2014-09-08 19:03                               ` Andreas Rohner
     [not found]                                 ` <540DFD66.1090904-hi6Y0CQ0nG0@public.gmane.org>
2014-09-09 18:55                                   ` Ryusuke Konishi

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=5404C686.4070800@gmx.net \
    --to=andreas.rohner-hi6y0cq0ng0@public.gmane.org \
    --cc=konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
    --cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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.