From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750936AbcB2U6l (ORCPT ); Mon, 29 Feb 2016 15:58:41 -0500 Received: from mail-qk0-f193.google.com ([209.85.220.193]:32857 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbcB2U6j (ORCPT ); Mon, 29 Feb 2016 15:58:39 -0500 Date: Mon, 29 Feb 2016 15:58:37 -0500 From: Tejun Heo To: Al Viro Cc: Tahsin Erdogan , Jan Kara , Jens Axboe , cgroups@vger.kernel.org, "Theodore Ts'o" , Nauman Rafique , linux-kernel@vger.kernel.org, Jan Kara Subject: Re: [PATCH block/for-linus] writeback: flush inode cgroup wb switches instead of pinning super_block Message-ID: <20160229205837.GX3965@htj.duckdns.org> References: <20160215210047.GN3965@htj.duckdns.org> <20160216182457.GO3741@mtj.duckdns.org> <20160217205721.GE14140@quack.suse.cz> <20160217210744.GA6479@mtj.duckdns.org> <20160217223009.GN14140@quack.suse.cz> <20160217230231.GC6479@mtj.duckdns.org> <20160229204724.GV3965@htj.duckdns.org> <20160229205428.GB17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160229205428.GB17997@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 29, 2016 at 08:54:28PM +0000, Al Viro wrote: > > This patch removes the problematic super_block pinning and instead > > makes generic_shutdown_super() flush in-flight wb switches. wb > > switches are now executed on a dedicated isw_wq so that they can be > > flushed and isw_nr_in_flight keeps track of the number of in-flight wb > > switches so that flushing can be avoided in most cases. > > Wait a bloody minute. What's to prevent shrink_dcache_for_umount() from > dirtying more inodes, triggering more of the same? Hmmm? The flushing is done after shrink_dcache_for_umount() and sync_filesystems(). Aren't inodes supposed to stay clean after that? > > - if (!atomic_inc_not_zero(&inode->i_sb->s_active)) > > - goto out_unlock; > > This would've failed for inodes on superblock in the middle of shutdown; > what's to do the same for the new variant? I don't follow. As long as no new writeback operations are initiated after flushing, none can be in flight for the super_block. Isn't that enough? Thanks. -- tejun