From: "Luis R. Rodriguez" <mcgrof@kernel.org> To: Bart Van Assche <Bart.VanAssche@wdc.com>, Benjamin Marzinski <bmarzins@redhat.com> Cc: "pavel@ucw.cz" <pavel@ucw.cz>, "darrick.wong@oracle.com" <darrick.wong@oracle.com>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "ming.lei@redhat.com" <ming.lei@redhat.com>, "rjw@rjwysocki.net" <rjw@rjwysocki.net>, "mcgrof@kernel.org" <mcgrof@kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "jikos@kernel.org" <jikos@kernel.org>, "len.brown@intel.com" <len.brown@intel.com>, "tytso@mit.edu" <tytso@mit.edu>, "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>, "ONeukum@suse.com" <ONeukum@suse.com>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nborisov@suse.com" <nborisov@suse.com>, "oleg.b.antonyan@gmail.com" <oleg.b.antonyan@gmail.com>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>, "jgross@suse.com" <jgross@suse.com>, "martin.petersen@oracle.com" <martin.petersen@oracle.com>, "dan.j.williams@intel.com" <dan.j.williams@intel.com>, "yu.chen.surf@gmail.com" <yu.chen.surf@gmail.com>, "oleksandr@natalenko.name" <oleksandr@natalenko.name>, "todd.e.brandt@linux.intel.com" <todd.e.brandt@linux.intel.com>, "jack@suse.cz" <jack@suse.cz> Subject: Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate Date: Thu, 30 Nov 2017 20:42:49 +0100 [thread overview] Message-ID: <20171130194249.GK729@wotan.suse.de> (raw) In-Reply-To: <1512061271.2774.10.camel@wdc.com> On Thu, Nov 30, 2017 at 05:01:13PM +0000, Bart Van Assche wrote: > It's great to see that you are making progress with this work :-) However, > what's not clear to me is what your (long-term) plan is for freezing > filesystems that e.g. exist on top of a md RAID1 block device? The original approach of doing a full swing kill on kthread freezing helpers in one shot was too much. We must therefore approach this turtle style and carefully. This patch series currently only addresses filesystems which have a freeze_fs() callback implemented, that's it. The rest of the kernel needs more work. So this work is far as I've gotten so far. Note, it does *not* remove the kthread freezing API calls on any other drivers, as such that should still work. > The md resync > thread must be stopped before a system is frozen. Today the md driver uses > the kthread freezing mechanism for that purpose. Do you have a plan for > handling the more complicated scenarios, e.g. a filesystem that exists on top > of an md device where the md device uses one or more files as backing store > and with the loop driver between the md device and the files? Nope not yet. It seems you have given this some thought though so you're help here is greatly appreciated. In fact the way we should see the long term 'kill kthread freezing' effort should be a collaborative one. I've never touched md, so folks more familiar with md should give this some thought. Can for instance md register_pm_notifier() and register_syscore_ops() and do handy work to pause some work to replace kthread freezing? Note that I believe a pm notifier is needed in case syscore_suspend() is not called, say on a suspend fail. > How about filesystems implemented in user space using the FUSE driver? Not sure, someone more familiar with FUSE drivers should chime in. Right now all this does is leverage filesystems which *do* implement freeze_fs() only, and removes the kthread freezing calls after that. That's all. It should not affect any other filesystems Likewise consider filesystems that implement freeze_super() instead (like gfs2) which don't hold sb->s_umount -- see commit 48b6bca6b7b8309 ("fs: add freeze_super/thaw_super fs hooks"). If its desirable to address those as well, it would seem a pair of non-locking iters somehow are needed. More work to be done. This all needs to be considered for the future as well. > Patch 6/11 of this series freezes user space processes before freezing > filesystems. Will that work for FUSE filesystems? It doesn't add new code which should negatively affect FUSE drivers. Long term if we wanted to address FUSE, it may require other work. In the future then fs_suspend_freeze() may need to work for different types of filesystems. Right now only filesystems which implement freeze_fs() are addressed. Luis
WARNING: multiple messages have this Message-ID (diff)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> To: Bart Van Assche <Bart.VanAssche@wdc.com>, Benjamin Marzinski <bmarzins@redhat.com> Cc: "pavel@ucw.cz" <pavel@ucw.cz>, "darrick.wong@oracle.com" <darrick.wong@oracle.com>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "ming.lei@redhat.com" <ming.lei@redhat.com>, "rjw@rjwysocki.net" <rjw@rjwysocki.net>, "mcgrof@kernel.org" <mcgrof@kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "jikos@kernel.org" <jikos@kernel.org>, "len.brown@intel.com" <len.brown@intel.com>, "tytso@mit.edu" <tytso@mit.edu>, "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>, "ONeukum@suse.com" <ONeukum@suse.com>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nborisov@suse.com" <nborisov@suse.com>, "oleg.b.antonyan@gmail.com" <oleg.b.antonyan@gmail.com>l Subject: Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate Date: Thu, 30 Nov 2017 20:42:49 +0100 [thread overview] Message-ID: <20171130194249.GK729@wotan.suse.de> (raw) In-Reply-To: <1512061271.2774.10.camel@wdc.com> On Thu, Nov 30, 2017 at 05:01:13PM +0000, Bart Van Assche wrote: > It's great to see that you are making progress with this work :-) However, > what's not clear to me is what your (long-term) plan is for freezing > filesystems that e.g. exist on top of a md RAID1 block device? The original approach of doing a full swing kill on kthread freezing helpers in one shot was too much. We must therefore approach this turtle style and carefully. This patch series currently only addresses filesystems which have a freeze_fs() callback implemented, that's it. The rest of the kernel needs more work. So this work is far as I've gotten so far. Note, it does *not* remove the kthread freezing API calls on any other drivers, as such that should still work. > The md resync > thread must be stopped before a system is frozen. Today the md driver uses > the kthread freezing mechanism for that purpose. Do you have a plan for > handling the more complicated scenarios, e.g. a filesystem that exists on top > of an md device where the md device uses one or more files as backing store > and with the loop driver between the md device and the files? Nope not yet. It seems you have given this some thought though so you're help here is greatly appreciated. In fact the way we should see the long term 'kill kthread freezing' effort should be a collaborative one. I've never touched md, so folks more familiar with md should give this some thought. Can for instance md register_pm_notifier() and register_syscore_ops() and do handy work to pause some work to replace kthread freezing? Note that I believe a pm notifier is needed in case syscore_suspend() is not called, say on a suspend fail. > How about filesystems implemented in user space using the FUSE driver? Not sure, someone more familiar with FUSE drivers should chime in. Right now all this does is leverage filesystems which *do* implement freeze_fs() only, and removes the kthread freezing calls after that. That's all. It should not affect any other filesystems Likewise consider filesystems that implement freeze_super() instead (like gfs2) which don't hold sb->s_umount -- see commit 48b6bca6b7b8309 ("fs: add freeze_super/thaw_super fs hooks"). If its desirable to address those as well, it would seem a pair of non-locking iters somehow are needed. More work to be done. This all needs to be considered for the future as well. > Patch 6/11 of this series freezes user space processes before freezing > filesystems. Will that work for FUSE filesystems? It doesn't add new code which should negatively affect FUSE drivers. Long term if we wanted to address FUSE, it may require other work. In the future then fs_suspend_freeze() may need to work for different types of filesystems. Right now only filesystems which implement freeze_fs() are addressed. Luis
next prev parent reply other threads:[~2017-11-30 19:42 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-29 23:23 [PATCH 00/11] fs: use freeze_fs on suspend/hibernate Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 01/11] fs: provide unlocked helper for freeze_super() Luis R. Rodriguez 2017-11-30 16:58 ` Jan Kara 2017-11-29 23:23 ` [PATCH 02/11] fs: provide unlocked helper thaw_super() Luis R. Rodriguez 2017-11-30 16:59 ` Jan Kara 2017-11-29 23:23 ` [PATCH 03/11] fs: add frozen sb state helpers Luis R. Rodriguez 2017-11-30 17:13 ` Jan Kara 2017-11-30 19:05 ` Luis R. Rodriguez 2017-12-01 11:47 ` Jan Kara 2017-12-01 21:13 ` Luis R. Rodriguez 2017-12-21 11:03 ` Jan Kara 2018-04-18 0:59 ` Luis R. Rodriguez 2018-04-18 10:12 ` Jan Kara 2018-04-20 18:49 ` Luis R. Rodriguez 2018-04-21 23:53 ` Jan Kara 2018-04-22 1:22 ` Luis R. Rodriguez 2018-04-22 2:53 ` Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 04/11] fs: distinguish between user initiated freeze and kernel initiated freeze Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 05/11] fs: add iterate_supers_excl() and iterate_supers_reverse_excl() Luis R. Rodriguez 2017-11-29 23:48 ` Rafael J. Wysocki 2017-11-29 23:48 ` Rafael J. Wysocki 2017-11-30 0:22 ` Luis R. Rodriguez 2017-11-30 0:22 ` Luis R. Rodriguez 2017-11-30 1:34 ` Dave Chinner 2017-11-30 1:34 ` Dave Chinner 2017-11-30 1:40 ` Rafael J. Wysocki 2017-11-30 1:40 ` Rafael J. Wysocki 2017-11-30 16:57 ` Jan Kara 2017-11-29 23:23 ` [PATCH 06/11] fs: freeze on suspend and thaw on resume Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 07/11] xfs: remove not needed freezing calls Luis R. Rodriguez 2017-11-30 16:21 ` Jan Kara 2017-11-30 20:32 ` Rafael J. Wysocki 2017-11-30 20:32 ` Rafael J. Wysocki 2017-11-30 23:30 ` Dave Chinner 2017-11-30 23:30 ` Dave Chinner 2017-11-30 23:40 ` Rafael J. Wysocki 2017-11-30 23:40 ` Rafael J. Wysocki 2017-11-29 23:23 ` [PATCH 08/11] ext4: " Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 09/11] f2fs: " Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 10/11] nilfs2: " Luis R. Rodriguez 2017-11-29 23:23 ` [PATCH 11/11] jfs: " Luis R. Rodriguez 2017-11-30 16:36 ` [PATCH 00/11] fs: use freeze_fs on suspend/hibernate Yu Chen 2017-11-30 16:41 ` Jiri Kosina 2017-11-30 16:50 ` Yu Chen 2017-12-01 19:05 ` Jeff Layton 2017-12-01 21:51 ` Dave Chinner 2017-11-30 17:01 ` Bart Van Assche 2017-11-30 17:01 ` Bart Van Assche 2017-11-30 19:42 ` Luis R. Rodriguez [this message] 2017-11-30 19:42 ` Luis R. Rodriguez 2017-11-30 20:53 ` Bart Van Assche 2017-11-30 20:53 ` Bart Van Assche 2017-11-30 20:53 ` Bart Van Assche 2017-11-30 21:03 ` Dave Chinner 2017-11-30 21:03 ` Dave Chinner 2017-11-30 21:51 ` Pavel Machek 2017-12-01 0:44 ` Luis R. Rodriguez 2017-12-13 1:09 ` Rafael J. Wysocki 2017-12-19 16:50 ` Luis R. Rodriguez
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20171130194249.GK729@wotan.suse.de \ --to=mcgrof@kernel.org \ --cc=Bart.VanAssche@wdc.com \ --cc=ONeukum@suse.com \ --cc=bmarzins@redhat.com \ --cc=boris.ostrovsky@oracle.com \ --cc=dan.j.williams@intel.com \ --cc=darrick.wong@oracle.com \ --cc=jack@suse.cz \ --cc=jgross@suse.com \ --cc=jikos@kernel.org \ --cc=len.brown@intel.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=ming.lei@redhat.com \ --cc=nborisov@suse.com \ --cc=oleg.b.antonyan@gmail.com \ --cc=oleksandr@natalenko.name \ --cc=pavel@ucw.cz \ --cc=rjw@rjwysocki.net \ --cc=todd.e.brandt@linux.intel.com \ --cc=tytso@mit.edu \ --cc=viro@zeniv.linux.org.uk \ --cc=yu.chen.surf@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.