From: Jan Kara <jack@suse.cz>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: Jan Kara <jack@suse.cz>, Al Viro <viro@ZenIV.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] writeback: Do not sync data dirtied after sync start
Date: Mon, 30 Sep 2013 11:31:49 +0200 [thread overview]
Message-ID: <20130930093149.GB28023@quack.suse.cz> (raw)
In-Reply-To: <20130928003119.GI6709@localhost>
On Sat 28-09-13 08:31:19, Wu Fengguang wrote:
> Hi Jan,
>
> On Thu, Sep 26, 2013 at 09:23:58PM +0200, Jan Kara wrote:
> > When there are processes heavily creating small files while sync(2) is
> > running, it can easily happen that quite some new files are created
> > between WB_SYNC_NONE and WB_SYNC_ALL pass of sync(2). That can happen
> > especially if there are several busy filesystems (remember that sync
> > traverses filesystems sequentially and waits in WB_SYNC_ALL phase on one
> > fs before starting it on another fs). Because WB_SYNC_ALL pass is slow
> > (e.g. causes a transaction commit and cache flush for each inode in
> > ext3), resulting sync(2) times are rather large.
>
> This is a very good change. An old problem that may worth noting here
> is that inode_dirtied_after() has a workaround for the inodes whose
> ->dirtied_when is never updated due to being constantly redirtied.
> That workaround still leaves a small time window that sync() may skip
> a should-be-synced inode. Since the problem existed before this patch
> so I'm fine with this change.
Thanks for review. Do you mean the situation when jiffies in
inode->dirtied_when essentially wrap around on 32-bit systems wrt current
time? Yes, that is still a problem for which I don't know a better fix than
the current workaround.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2013-09-30 9:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 19:23 [PATCH v2] writeback: Do not sync data dirtied after sync start Jan Kara
2013-09-27 0:55 ` Dave Chinner
2013-09-27 9:37 ` Jan Kara
2013-09-27 23:22 ` Dave Chinner
2013-09-28 0:31 ` Fengguang Wu
2013-09-30 9:31 ` Jan Kara [this message]
2013-10-03 13:20 ` Fengguang Wu
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=20130930093149.GB28023@quack.suse.cz \
--to=jack@suse.cz \
--cc=fengguang.wu@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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).