Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754088AbbHRTyq (ORCPT ); Tue, 18 Aug 2015 15:54:46 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:35876 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751199AbbHRTym (ORCPT ); Tue, 18 Aug 2015 15:54:42 -0400 Date: Tue, 18 Aug 2015 12:54:39 -0700 From: Tejun Heo To: Jan Kara Cc: Jens Axboe , Jan Kara , Eryu Guan , xfs@oss.sgi.com, axboe@fb.com, Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes Message-ID: <20150818195439.GB15739@mtj.duckdns.org> References: <20150812101204.GE17933@dhcp-13-216.nay.redhat.com> <20150813004435.GN3902@dastard> <20150813224415.GG4496@mtj.duckdns.org> <20150814111408.GB8710@quack.suse.cz> <20150817200254.GG21075@mtj.duckdns.org> <20150818091603.GA12317@quack.suse.cz> <20150818174718.GA15739@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150818174718.GA15739@mtj.duckdns.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1391 Lines: 33 Hello, On Tue, Aug 18, 2015 at 10:47:18AM -0700, Tejun Heo wrote: > Hmm... the only possibility I can think of is tot_write_bandwidth > being zero when it shouldn't be. I've been staring at the code for a > while now but nothing rings a bell. Time for another debug patch, I > guess. So, I can now reproduce the bug (it takes a lot of trials but lowering the number of tested files helps quite a bit) and instrumented all the early exit paths w/o the fix patch. bdi_has_dirty_io() and wb_has_dirty_io() are never out of sync with the actual dirty / io lists even when the test 048 fails, so the bug at least is not caused by writeback skipping due to buggy bdi/wb_has_dirty_io() result. Whenever it skips, all the lists are actually empty (verified while holding list_lock). One suspicion I have is that this could be a subtle timing issue which is being exposed by the new short-cut path. Anything which adds delay seems to make the issue go away. Dave, does anything ring a bell? As for the proposed I_DIRTY_TIME fix, I think it'd be a good idea to merge it. It fixes a clear brekage regardless of this xfs issue. Thanks. -- tejun -- 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/