From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: Regression in suspend to ram in 2.6.31-rc kernels Date: Tue, 8 Sep 2009 21:48:33 +0200 Message-ID: <200909082148.33872.rjw@sisk.pl> References: <87ljkvmt71.fsf@devron.myhome.or.jp> <20090908190614.GA18545@lst.de> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from ogre.sisk.pl ([217.79.144.158]:58585 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751517AbZIHTri (ORCPT ); Tue, 8 Sep 2009 15:47:38 -0400 In-Reply-To: <20090908190614.GA18545@lst.de> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Christoph Hellwig Cc: OGAWA Hirofumi , Zdenek Kabelac , Linux Kernel Mailing List , linux-mmc@vger.kernel.org, viro@zeniv.linux.org.uk On Tuesday 08 September 2009, Christoph Hellwig wrote: > On Fri, Sep 04, 2009 at 09:47:46AM +0900, OGAWA Hirofumi wrote: > > Well, that commit seems a bit strange. It calls fat_clusters_flush() > > unconditionally without checking sb->s_dirt. However, if my guess is > > right, "sync after removed event" itself sounds like the issue in > > suspend process. > > The idea of ->sync_fs is that we always perform the sync activity, > and not just the usual background superblock writeback trigerred by > s_dirt. If FAT doesn't need that and never has races around s_dirt > you can add the check back, but I would recommend against it. > > Also when you hack around this in FAt MMC will still fail with every > other filesystem. So, what should be done in your opinion? Rafael