Re: [xfs-masters] Re: freeze vs freezer

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Tuesday, 1 of July 2008, Dave Chinner wrote:
> On Tue, Jul 01, 2008 at 04:35:43PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 1 of July 2008, Dave Chinner wrote:
> > > On Tue, Jul 01, 2008 at 12:38:41AM +0200, Rafael J. Wysocki wrote:
> > > > 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.
> > > 
> > > Yes, but you still haven't answered the original question - What are
> > > you going to do with sync I/O that leaves a process in D state
> > > because you've prevented the I/O from being completed?
> > 
> > I don't want to intercept those processes, just allow them to block on that I/O.
> 
> So you're going to allow them to go to D state somewhere. Ok, so
> what's the problem with blocking them in vfs_check_frozen(), then?
> 
> > Do all of the filesystems implement the freezing?
> 
> Most of the major ones - those that implement ->write_super_lockfs()
> should work just fine.

Okay, so we can do that.

I'm surely not against freezing of the filesystems before hibernation at least.
In fact we tried that in the past, but there were some locking problems I was
unable to resolve at that time.

Unfortunately I'm not very familiar with the VFS and filesystems code, so some
experts' help would be very much appreciated.

Thanks,
Rafael