Message-Id: <200807010038.43362.rjw@sisk.pl>
Date:	Tue, 1 Jul 2008 00:38:41 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Dave Chinner <david@...morbit.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>, xfs-masters@....sgi.com,
	Elias Oltmanns <eo@...ensachen.de>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Kyle Moffett <mrmacman_g4@....com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	David Chinner <dgc@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [xfs-masters] Re: freeze vs freezer

On Tuesday, 1 of July 2008, Dave Chinner wrote:
> On Mon, Jun 30, 2008 at 11:00:43PM +0200, Rafael J. Wysocki wrote:
> > On Monday, 30 of June 2008, Dave Chinner wrote:
> > > On Sun, Jun 29, 2008 at 11:37:31PM -0700, Jeremy Fitzhardinge wrote:
> > > > Dave Chinner wrote:
> > > >> On Mon, Jun 30, 2008 at 01:22:47AM +0200, Rafael J. Wysocki wrote:
> > > >>> Well, it seems we can handle this on the block layer level, by temporarily
> > > >>> replacing the elevator with something that will selectively prevent fs I/O
> > > >>> from reaching the layers below it.
> > > >>
> > > >> Why? What part of freeze_bdev() doesn't work for you?
> > > >
> > > > Well, my original problem - which is still an issue - is that a process  
> > > > writing to a frozen XFS filesystem is stuck in D state, and therefore  
> > > > cannot be frozen as part of suspend.
> > 
> > I thought we were talking about the post-freezer situation.
> > 
> > > Silly me - how could I forget the three headed monkey getting in
> > > the way of our happy trip to beer island?
> > > 
> > > Seriously, though, how is stopping I/O in the elevator is going to
> > > change that?
> > 
> > We can do that after creating the image and before we let devices run again.
> > This way we won't need to worry about the freezer.
> 
> You're suggesting that you let processes trying to do I/O continue
> until *after* the memory image is taken?

I'm not going to let the data get to the disk.

> How is that going to work? 
> You've got to quiesce the filesystems totally *before* taking an image
> of memory - it's the only way to guarantee that they are the
> in-memory state and on disk state are consistent state on resume.

No, it's not the only way.

We have to ensure that the fs data that did't make it to the disk(s)
before creating the snapshot image will not be written to the disk(s) after
the image has been created.  In theory one can think of many ways to achieve
that and the freezing of filesystems is certainly one of those.

> Don't re-invent the wheel - use the API we already have that does
> exactly what needs to be done.
> 
> > > What do you do with a sync I/O (read or write)? The 
> > > process is going to have to go to sleep somewhere in D state waiting
> > > for that I/O to complete.  If you're going to intercept such
> > > processes somewhere else to do something magic, then why not put
> > > that magic in vfs_check_frozen()?
> > 
> > This might work too, but it would be nice to do something independent of the
> > freezer, so that we can drop the freezer when we want and not when we are
> > forced to.
> 
> vfs_check_frozen() is completely independent of the process freezer.

Well, can you please tell me how exactly that works, then?

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists