From: Pavel Machek <pavel@ucw.cz>
To: Christoph Hellwig <hch@infradead.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, David Chinner <dgc@sgi.com>,
Nigel Cunningham <ncunningham@linuxmail.org>,
Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com
Subject: Re: [PATCH] Freeze bdevs when freezing processes.
Date: Tue, 24 Oct 2006 23:43:22 +0200 [thread overview]
Message-ID: <20061024214322.GA5652@elf.ucw.cz> (raw)
In-Reply-To: <20061024213342.GA22552@infradead.org>
Hi!
On Tue 2006-10-24 22:33:42, Christoph Hellwig wrote:
> On Tue, Oct 24, 2006 at 11:26:48PM +0200, Pavel Machek wrote:
> > > No, that's definitly not enough. You need to freeze_bdev to make sure
> > > data is on disk in the place it's expected by the filesystem without
> > > starting a log recovery.
> >
> > I believe log recovery is okay in this case.
> >
> > It can only happen when kernel dies during suspend or during
> > resume... And log recovery seems okay in that case. We even guarantee
> > that user did not loose any data -- by using sys_sync() after userland
> > is stopped -- but let's not overdo over protections.
>
> You're still entirely missing the problem.
>
> Take a look at http://www.opengroup.org/onlinepubs/007908799/xsh/sync.html
> and the linux sync(2) manpage. The only thing sync guarantees is writing
> out all in-memory data to disk. It doesn't even gurantee completion,
> although we've been synchronous in Linux for a while.
Ok, I assume sys_sync is synchronous, but that's okay.
> What it does not gurantee is where on disk the data is located. Now for
> a journaling filesystem pushing everything to the log is the easiest way
> to complete sync, and it's perfectly valid - if the system crashes after
> the sync and before data is written back to it's normal place on disk
> the system notices it's not been unmounted cleanly and will do a log
> recovery. In the suspend case however the system neither crashes nor
> is unmounted - thus the filesystem doesn't know it has to recover the
> log. We have to choices to fix this:
>
> (1) force a log recovery of an already mounted and in use filesystem
> (2) make sure data is in the right place before suspending
>
> (1) is pretty nasty, and hard to do across filesystems. (2) is already
> implemented and easily useable by the suspend code.
No, there's no need to do either (1) or (2) in "machine suspended and
resumed successfully". In that case, machine just continues as if no
suspend has happened.
In fact I could remove sys_sync() from freezer. suspend code would
still be correct.
That sys_sync() only matters in case of suspend but machine died
during resume... and in that case we know we crashed, and journal
recovery is okay.
I do know how journaling works (from 10000feet, anyway), and it is
okay in this case.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-10-24 22:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1161576735.3466.7.camel@nigel.suspend2.net>
[not found] ` <200610231236.54317.rjw@sisk.pl>
2006-10-24 14:44 ` [PATCH] Freeze bdevs when freezing processes David Chinner
2006-10-24 15:29 ` Rafael J. Wysocki
2006-10-24 16:27 ` Oleg Verych
2006-10-25 8:05 ` Pavel Machek
2006-10-24 16:33 ` David Chinner
2006-10-24 21:37 ` Pavel Machek
2006-10-25 0:13 ` David Chinner
2006-10-25 8:10 ` Pavel Machek
2006-10-25 8:38 ` David Chinner
2006-10-25 8:47 ` Pavel Machek
2006-10-25 12:32 ` Rafael J. Wysocki
2006-10-25 13:23 ` Nigel Cunningham
[not found] ` <200610252105.56862.rjw@sisk.pl>
2006-10-26 7:30 ` David Chinner
2006-10-26 8:18 ` Nigel Cunningham
2006-10-26 8:48 ` Rafael J. Wysocki
2006-10-26 8:57 ` David Chinner
2006-10-26 9:11 ` Rafael J. Wysocki
2006-10-27 1:38 ` David Chinner
2006-10-27 14:37 ` Rafael J. Wysocki
2006-10-29 17:35 ` Pavel Machek
[not found] ` <200610300029.25555.rjw@sisk.pl>
2006-10-29 23:46 ` Nigel Cunningham
2006-10-26 9:18 ` Nigel Cunningham
2006-10-26 9:08 ` Rafael J. Wysocki
2006-10-24 17:06 ` Christoph Hellwig
2006-10-24 21:26 ` Pavel Machek
2006-10-24 21:33 ` Christoph Hellwig
2006-10-24 21:43 ` Pavel Machek [this message]
2006-10-24 22:19 ` Nigel Cunningham
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=20061024214322.GA5652@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@osdl.org \
--cc=dgc@sgi.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@linuxmail.org \
--cc=rjw@sisk.pl \
--cc=xfs@oss.sgi.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox