From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH v3] writeback: Do not sync data dirtied after sync start Date: Mon, 30 Sep 2013 09:12:14 +1000 Message-ID: <20130929231214.GH26872@dastard> References: <1380275080-31736-1-git-send-email-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , Wu Fengguang , linux-fsdevel@vger.kernel.org, dchinner@redhat.com To: Jan Kara Return-path: Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:44518 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753012Ab3I2XMT (ORCPT ); Sun, 29 Sep 2013 19:12:19 -0400 Content-Disposition: inline In-Reply-To: <1380275080-31736-1-git-send-email-jack@suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Sep 27, 2013 at 11:44:40AM +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. > > The following script reproduces the problem: > > function run_writers > { > for (( i = 0; i < 10; i++ )); do > mkdir $1/dir$i > for (( j = 0; j < 40000; j++ )); do > dd if=/dev/zero of=$1/dir$i/$j bs=4k count=4 &>/dev/null > done & > done > } > > for dir in "$@"; do > run_writers $dir > done > > sleep 40 > time sync > ====== > > Fix the problem by disregarding inodes dirtied after sync(2) was called > in the WB_SYNC_ALL pass. To allow for this, sync_inodes_sb() now takes a > time stamp when sync has started which is used for setting up work for > flusher threads. > > To give some numbers, when above script is run on two ext4 filesystems on > simple SATA drive, the average sync time from 10 runs is 267.549 seconds > with standard deviation 104.799426. With the patched kernel, the average > sync time from 10 runs is 2.995 seconds with standard deviation 0.096. > > Signed-off-by: Jan Kara This version looks good. Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com