From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:60382 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752217AbeBXD1m (ORCPT ); Fri, 23 Feb 2018 22:27:42 -0500 Date: Sat, 24 Feb 2018 03:27:40 +0000 From: "Luis R. Rodriguez" To: "Rafael J. Wysocki" Cc: Bart Van Assche , "darrick.wong@oracle.com" , "mcgrof@kernel.org" , "jlayton@redhat.com" , "jikos@kernel.org" , "jack@suse.cz" , "david@fromorbit.com" , "lsf-pc@lists.linux-foundation.org" , "linux-fsdevel@vger.kernel.org" Subject: Re: [LSF/MM TOPIC] Phasing out kernel thread freezing Message-ID: <20180224032740.GC14069@wotan.suse.de> References: <20180126090923.GD12447@wotan.suse.de> <20180131191016.GC4841@magnolia> <1517784089.26121.2.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Feb 05, 2018 at 09:28:37AM +0100, Rafael J. Wysocki wrote: > On Sun, Feb 4, 2018 at 11:41 PM, Bart Van Assche wrote: > > On Wed, 2018-01-31 at 11:10 -0800, Darrick J. Wong wrote: > >> For a brief moment I pondered whether it would make sense to make > >> filesystems part of the device model so that the suspend code could work > >> out fs <-> bdev dependencies and know in which order to freeze > >> filesystems and quiesce devices, but every time I go digging into how > >> all those macros work I get confused and my eyes glaze over, so I don't > >> know if this is at all a good idea or just confused ramblings. > > > > If we have to go this way: shouldn't we introduce a new abstraction > > ("storage stack element" or similar) rather than making filesystems part of > > the device model? > > That would be my approach. > > Trying to "suspend" filesystems at the same time as I/O devices (and > all of that asynchronously) may be problematic for ordering reasons > and similar. Oh look, another ordering issue. And this is why I was not a fan of the device link API even though that is what we got merged. Moving on... > Moreover, during hibernation devices are suspended for two times (and > resumed in between, of course) whereas filesystems only need to be > "suspended" once. >>From your point of view yes, but actually internally the VFS layer or filesystems themselves may end up re-using this mechanism later for other things like -- snapshotting. And if some folks have it the way they want it, we may need a dependency map between filesystems anyway for filesystem specific reasons. > With that in mind, I would add a mechanism allowing filesystems (and > possibly other components of the storage stack) to register a set of > callbacks for suspend and resume and then invoking those callbacks in > a specific order. That's what I had done in my series, the issue here is order. Order in my series is simple but should work for starters, later however I suspect we'll need something more robust to help. Luis