lkml.org 
[lkml]   [2008]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [xfs-masters] Re: freeze vs freezer
    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? 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.

    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.

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com


    \
     
     \ /
      Last update: 2008-07-01 00:23    [W:2.997 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site