public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: David Chinner <dgc@sgi.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	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: Wed, 25 Oct 2006 10:10:01 +0200	[thread overview]
Message-ID: <20061025081001.GL5851@elf.ucw.cz> (raw)
In-Reply-To: <20061025001331.GP8394166@melbourne.sgi.com>

Hi!

> > > > Do you mean calling sys_sync() after the userspace has been frozen
> > > > may not be sufficient?
> > > 
> > > In most cases it probably is, but sys_sync() doesn't provide any
> > > guarantees that the filesystem is not being used or written to after
> > > it completes. Given that every so often I hear about an XFS filesystem
> > > that was corrupted by suspend, I don't think this is sufficient...
> > 
> > Userspace is frozen. There's noone that can write to the XFS
> > filesystem.
> 
> Sure, no new userspace processes can write data, but what about the
> internal state of the filesystem?
> 
> All a sync guarantees is that the filesystem is consistent when the
> sync returns and XFS provides this guarantee by writing all data and
> ensuring all metadata changes are logged so if a crash occurs it can
> be recovered (which provides the sync guarantee). hence after a
> sys_sync(), XFS will still have lots of dirty metadata that needs to
> be written to disk at some time in the future so the transactions
> can be removed from the log.
> 
> This dirty metadata can be flushed at any time, and the dirty state
> is kept in XFS structures and not always in page structures (think
> multipage metadata buffers). Hence I cannot see how suspend can
> guarantee that it has saved all the dirty data in XFS, nor
> restore it correctly on resume. Once you toss dirty metadata that
> is currently in the log, further operations will result in that log
> transaction being overwritten without it ever being written to disk.
> That then means any subsequent operations after resume will corrupt
> the filesystem....
> 
> Hence the only way to correctly rebuild the XFS state on resume is
> to quiesce the filesystem on suspend and thaw it on resume so as to
> trigger log recovery.

No, during suspend/resume, memory image is saved, and no state is
lost. We would not even have to do sys_sync(), and suspend/resume
would still work properly.

sys_sync() is there only to limit damage in case of suspend/resume
failure.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2006-10-25  8:11 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 [this message]
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
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=20061025081001.GL5851@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@osdl.org \
    --cc=dgc@sgi.com \
    --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