Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754111AbbHXI4G (ORCPT ); Mon, 24 Aug 2015 04:56:06 -0400 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:60327 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980AbbHXI4E (ORCPT ); Mon, 24 Aug 2015 04:56:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+CgCz29pVPEDvLHldgxpUZwKCV6cSDAEBAQEBAQaDQ5IihXUCAgEBAkVkTQEBAQEBAQcBAQEBQT+EIwEBAQMBJxMRAQojBQsIAw4FBQklDwURFAMHGhOIJgcOtm0Bj0EBAQEBAQUBAQEBHhmGCoU0hQoHgxiBFAWHJoZuhAqDFoUGh2mBToQwiG+LZoQ2LDMBgksBAQE Date: Mon, 24 Aug 2015 18:55:49 +1000 From: Dave Chinner To: Eryu Guan Cc: Jens Axboe , Jan Kara , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, axboe@fb.com, linux-fsdevel@vger.kernel.org, Jan Kara , Tejun Heo , kernel-team@fb.com Subject: Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes Message-ID: <20150824085549.GB714@dastard> References: <20150818174718.GA15739@mtj.duckdns.org> <20150818195439.GB15739@mtj.duckdns.org> <20150818215611.GD3902@dastard> <20150821102053.GL17933@dhcp-13-216.nay.redhat.com> <20150822003025.GS3902@dastard> <20150822044609.GM17933@dhcp-13-216.nay.redhat.com> <20150824011123.GA714@dastard> <20150824031816.GO17933@dhcp-13-216.nay.redhat.com> <20150824062425.GU3902@dastard> <20150824083437.GP17933@dhcp-13-216.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150824083437.GP17933@dhcp-13-216.nay.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2570 Lines: 81 On Mon, Aug 24, 2015 at 04:34:37PM +0800, Eryu Guan wrote: > On Mon, Aug 24, 2015 at 04:24:25PM +1000, Dave Chinner wrote: > > On Mon, Aug 24, 2015 at 11:18:16AM +0800, Eryu Guan wrote: > > > On Mon, Aug 24, 2015 at 11:11:23AM +1000, Dave Chinner wrote: > > > > > > > > Eryu, can you change the way you run the event trace to be: > > > > > > > > $ sudo trace-cmd -o ./check > > > > > > > > rather than running the trace as a background operation elsewhere? > > > > Maybe that will give better results. > [snip] > > Anyway, Eryum long and short of it is that you don't need to worry > > about testing all the different combinations - we now know that the > > completion events are occurring, so let's focus on whether the sync > > code is not waiting for them correctly. Can you trace the following > > events: > > > > xfs_log_force > > xfs_setfilesize > > writeback_queue > > writeback_exec > > writeback_start > > writeback_queue_io > > writeback_written > > writeback_pages_written > > > > basically I'm trying to see if we've got all the BDI events as we'd > > expect then to be queued and run for sync, and when the ->sync_fs > > call occurs during the sync process before shutdown and unmount... > > I collected two versions of trace info with crc enabled. > > http://128.199.137.77/writeback-crc/ > > This version traced the same events as previous runs. > > http://128.199.137.77/writeback-crc-v2/ > > And this version only traced the events you listed above. OK, I'll look into these later. > And the results of other tests to check(all done with v4 xfs, with no > tracepoints enabled): > > > Other things to check (separately): > > - change godown to godown -f > > Passed 100 loops. Yup, I expected that from the last set of traces - the "-f" flag triggers a log force before shutdown, and that flushes out transactions that sync missed. > > - add a "sleep 5" before running godown after sync > > Failed, if you need the trace info please let me know. Expected, still nothing to flush transactions before shutdown. > > - add a "sleep 5; sync" before running godown > > Passed 100 loops. expected - sync flushed the transactions it missed on the first pass. Thanks for running these tests! Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/