From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fengguang Wu Subject: Re: [PATCH v2] writeback: Do not sync data dirtied after sync start Date: Thu, 3 Oct 2013 21:20:01 +0800 Message-ID: <20131003132001.GA25934@localhost> References: <1380223438-26381-1-git-send-email-jack@suse.cz> <20130928003119.GI6709@localhost> <20130930093149.GB28023@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from mga01.intel.com ([192.55.52.88]:15558 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753691Ab3JCNUI (ORCPT ); Thu, 3 Oct 2013 09:20:08 -0400 Content-Disposition: inline In-Reply-To: <20130930093149.GB28023@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Sep 30, 2013 at 11:31:49AM +0200, Jan Kara wrote: > 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. > Yes, that is still a problem for which I don't know a better fix than > the current workaround. OK, that's fine. I don't have ideas on this, either. Thanks, Fengguang