From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751415AbdK3UyB (ORCPT ); Thu, 30 Nov 2017 15:54:01 -0500 Received: from esa4.hgst.iphmx.com ([216.71.154.42]:25091 "EHLO esa4.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750801AbdK3Ux5 (ORCPT ); Thu, 30 Nov 2017 15:53:57 -0500 X-IronPort-AV: E=Sophos;i="5.45,343,1508774400"; d="scan'208";a="63673608" From: Bart Van Assche To: "bmarzins@redhat.com" , "mcgrof@kernel.org" CC: "boris.ostrovsky@oracle.com" , "ONeukum@suse.com" , "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "nborisov@suse.com" , "oleg.b.antonyan@gmail.com" , "linux-pm@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "pavel@ucw.cz" , "darrick.wong@oracle.com" , "viro@zeniv.linux.org.uk" , "ming.lei@redhat.com" , "dan.j.williams@intel.com" , "rjw@rjwysocki.net" , "jgross@suse.com" , "oleksandr@natalenko.name" , "yu.chen.surf@gmail.com" , "todd.e.brandt@linux.intel.com" , "martin.petersen@oracle.com" , "linux-fsdevel@vger.kernel.org" , "jikos@kernel.org" , "len.brown@intel.com" , "tytso@mit.edu" , "jack@suse.cz" Subject: Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate Thread-Topic: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate Thread-Index: AQHTaWkokX0EHafY40GmmRSAvi1ZP6MtJtKAgAAtKYCAABPZgA== Date: Thu, 30 Nov 2017 20:53:52 +0000 Message-ID: <1512075231.2774.17.camel@wdc.com> References: <20171129232356.28296-1-mcgrof@kernel.org> <1512061271.2774.10.camel@wdc.com> <20171130194249.GK729@wotan.suse.de> In-Reply-To: <20171130194249.GK729@wotan.suse.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@wdc.com; x-originating-ip: [199.255.44.171] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0401MB1534;20:uozY/oLjat+Z8MW4721S7PIGSwNmx7R5YDvVz2z2Y8tKx4LllSWixFIzcHWX7hN7jyLw4Km56Z491UYP2ZeSrPcNqimH95YZl6w/9/C/84rBME4bFrd01VfdSBIrbKWqL93PbF6fugA1Hgpxm+sgjfIXO+t8nRLQu4A3sgVaWxw= x-ms-office365-filtering-correlation-id: 0c7a206a-b4d2-4fb0-e845-08d538347708 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286);SRVR:CY1PR0401MB1534; x-ms-traffictypediagnostic: CY1PR0401MB1534: wdcipoutbound: EOP-TRUE x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011);SRVR:CY1PR0401MB1534;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:CY1PR0401MB1534; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(346002)(366004)(376002)(189002)(199003)(24454002)(377424004)(54906003)(229853002)(53936002)(3846002)(86362001)(15650500001)(189998001)(68736007)(4001150100001)(25786009)(6246003)(2501003)(97736004)(6506006)(7736002)(305945005)(101416001)(6436002)(6486002)(5660300001)(6512007)(103116003)(54356011)(3280700002)(2950100002)(33646002)(3660700001)(106356001)(105586002)(7416002)(2906002)(99286004)(316002)(2900100001)(66066001)(72206003)(478600001)(39060400002)(8936002)(4326008)(36756003)(8676002)(77096006)(110136005)(81166006)(6116002)(76176010)(81156014)(14454004)(102836003);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1534;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8F388E6E5968B94FAA774C73F77B55F3@namprd04.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c7a206a-b4d2-4fb0-e845-08d538347708 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 20:53:52.7914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1534 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vAUKs82k001198 On Thu, 2017-11-30 at 20:42 +0100, Luis R. Rodriguez wrote: > On Thu, Nov 30, 2017 at 05:01:13PM +0000, Bart Van Assche wrote: > > 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. Sorry but I don't think that a solution can be based on a notifier mechanism. Freezing has to happen in the order in which drivers and filesystems have been stacked (filesystem > md device > filesystem for the above example). Since the order in which notifiers are called is related to the order in which notifiers have been registered I don't think that a solution for the example I described can be based on notifiers. What I think we need is a mechanism for traversing the storage stack that includes block drivers and an equivalent of freeze_fs() for block drivers. Freezing should occur by calling the freeze_fs() methods for each storage layer starting at the top of the storage stack and proceeding towards the bottom. Bart.