Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934579AbbGHLUs (ORCPT ); Wed, 8 Jul 2015 07:20:48 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:40486 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932791AbbGHLUn (ORCPT ); Wed, 8 Jul 2015 07:20:43 -0400 Date: Wed, 8 Jul 2015 13:20:41 +0200 From: Pavel Machek To: "Rafael J. Wysocki" Cc: Alan Stern , Oliver Neukum , Dave Chinner , Henrique de Moraes Holschuh , Len Brown , Len Brown , One Thousand Gnomes , "linux-kernel@vger.kernel.org" , Linux PM list Subject: Re: [PATCH 1/1] suspend: delete sys_sync() Message-ID: <20150708112041.GB29356@amd> References: <8185914.90oAZWnb5N@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8185914.90oAZWnb5N@vostro.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2754 Lines: 58 On Wed 2015-07-08 00:20:05, Rafael J. Wysocki wrote: > On Tuesday, July 07, 2015 11:03:20 AM Alan Stern wrote: > > On Tue, 7 Jul 2015, Oliver Neukum wrote: > > > > > > he (or she) pulls the storage device out of the system, moves it to another > > > > system, makes changes (say removes the file written to by the process above, > > > > so the blocks previously occupied by that file are now used for some metadata) > > > > and moves the storage back to the suspended system. The system is resumed > > > > and the writing process continues writing possibly to the wrong blocks and > > > > corrupts the filesystem. > > > > > > That is a tough nut. But that's not a reason to make it worse. > > > I'd say there's no reason not to use a secondary interface to > > > suspend without syncing or to extend or introduce such an interface > > > if the API is deficient. > > > > Indeed, the problem Rafael outlined always exists whether or not the > > kernel does a sync. Even if no I/O is in progress when the system goes > > to sleep, if the user moves a portable storage device with a mounted > > filesystem to another computer and updates it before waking the system > > up, corruption is highly likely. > > > > In principle this could be solved by adding suspend/resume callbacks to > > filesystems. For example, the resume callback could verify that the > > superblock had not been changed since the suspend occurred. Or there > > could be some other simple way of determining that the filesystem had > > not been remounted and changed. > > > > Either way, this is irrelevant to the question of whether the kernel > > should issue a sync when suspending. > > well, that depends on what the purpose of the sync is supposed to be. > > If it is there to prevent users from corrupting their filesystems as a result > of a mistake, it is insufficient. If it's there for other reasons, I'm wondering > what those reasons are (on systems that suspend and resume reliably, because the > original reason to put it in there was to reduce the damage from suspend/resume > crashes). I put it there, and there were more reasons than "crashes" to put it there. 1) crashes. 2) battery is quite likely to run out in suspended machine. 3) if someone pulls the stick and puts it in other machine, I wanted consistent filesystem at least after journal replay. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/