Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Josh Boyer]

On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday, May 25, 2012, Josh Boyer wrote:
>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
>> >>
>> >>     Freeze all filesystems during system suspend and (kernel-driven)
>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
>> >>     them during the subsequent resume with the help of thaw_supers().
>> >>
>> >>     This makes filesystems stay in a consistent state in case something
>> >>     goes wrong between system suspend (or hibernation) and the subsequent
>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
>> >>     particular, this should help to solve a long-standing issue that, in
>> >>     some cases, during resume from hibernation the boot loader causes the
>> >>     journal to be replied for the filesystem containing the kernel image
>> >>     and/or initrd causing it to become inconsistent with the information
>> >>     stored in the hibernation image.
>> >>
>> >>     The user-space-driven hibernation (s2disk) is not covered by this
>> >>     change, because the freezing of filesystems prevents s2disk from
>> >>     accessing device special files it needs to do its job.
>> >>
>> >>     This change is based on earlier work by Nigel Cunningham.
>> >>
>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>> >>
>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
>>
>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
>> our tree with a comment that says "rebase" and I don't see it in the
>> linux-next tree at all.
>>
>> Did if fall through the cracks or was it NAKed somewhere?
>
> No, it wasn't in principle. There were some comments I haven't addressed yet.

Dredging up a really old thread, sorry.

We're still carrying this patch along in Fedora.  Should we drop it at
this point, or is it still eventually going to head upstream?

josh

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Josh Boyer]

On Tue, Dec 17, 2013 at 11:03 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Friday, May 25, 2012, Josh Boyer wrote:
>>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
>>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
>>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
>>> >>
>>> >>     Freeze all filesystems during system suspend and (kernel-driven)
>>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
>>> >>     them during the subsequent resume with the help of thaw_supers().
>>> >>
>>> >>     This makes filesystems stay in a consistent state in case something
>>> >>     goes wrong between system suspend (or hibernation) and the subsequent
>>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
>>> >>     particular, this should help to solve a long-standing issue that, in
>>> >>     some cases, during resume from hibernation the boot loader causes the
>>> >>     journal to be replied for the filesystem containing the kernel image
>>> >>     and/or initrd causing it to become inconsistent with the information
>>> >>     stored in the hibernation image.
>>> >>
>>> >>     The user-space-driven hibernation (s2disk) is not covered by this
>>> >>     change, because the freezing of filesystems prevents s2disk from
>>> >>     accessing device special files it needs to do its job.
>>> >>
>>> >>     This change is based on earlier work by Nigel Cunningham.
>>> >>
>>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>>> >>
>>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
>>>
>>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
>>> our tree with a comment that says "rebase" and I don't see it in the
>>> linux-next tree at all.
>>>
>>> Did if fall through the cracks or was it NAKed somewhere?
>>
>> No, it wasn't in principle. There were some comments I haven't addressed yet.
>
> Dredging up a really old thread, sorry.
>
> We're still carrying this patch along in Fedora.  Should we drop it at
> this point, or is it still eventually going to head upstream?

Fixed Rafael's email address.  (Double sorry.)

josh

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Pavel Machek]

Hi!

> >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> >>> our tree with a comment that says "rebase" and I don't see it in the
> >>> linux-next tree at all.
> >>>
> >>> Did if fall through the cracks or was it NAKed somewhere?
> >>
> >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> >
> > Dredging up a really old thread, sorry.
> >
> > We're still carrying this patch along in Fedora.  Should we drop it at
> > this point, or is it still eventually going to head upstream?

I'd say drop.

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

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Dave Chinner]

On Wed, Dec 18, 2013 at 12:08:43AM +0100, Pavel Machek wrote:
> Hi!
> 
> > >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> > >>> our tree with a comment that says "rebase" and I don't see it in the
> > >>> linux-next tree at all.
> > >>>
> > >>> Did if fall through the cracks or was it NAKed somewhere?
> > >>
> > >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> > >
> > > Dredging up a really old thread, sorry.
> > >
> > > We're still carrying this patch along in Fedora.  Should we drop it at
> > > this point, or is it still eventually going to head upstream?
> 
> I'd say drop.

I disagree - given the problem it is resolving leads to silent
filesystem corruption, this patch should be considered somewhat of a
priority to push...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Pavel Machek]

On Wed 2013-12-18 10:31:52, Dave Chinner wrote:
> On Wed, Dec 18, 2013 at 12:08:43AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> > > >>> our tree with a comment that says "rebase" and I don't see it in the
> > > >>> linux-next tree at all.
> > > >>>
> > > >>> Did if fall through the cracks or was it NAKed somewhere?
> > > >>
> > > >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> > > >
> > > > Dredging up a really old thread, sorry.
> > > >
> > > > We're still carrying this patch along in Fedora.  Should we drop it at
> > > > this point, or is it still eventually going to head upstream?
> > 
> > I'd say drop.
> 
> I disagree - given the problem it is resolving leads to silent
> filesystem corruption, this patch should be considered somewhat of a
> priority to push...

Umm. Ok, I forgot what it does, really.

So... for few years now suspend corrupts data on XFS? And Fedora has
the fix but it is not in mainline? That does not sound right...

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

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Rafael J. Wysocki]

On Tuesday, December 17, 2013 11:04:46 AM Josh Boyer wrote:
> On Tue, Dec 17, 2013 at 11:03 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> On Friday, May 25, 2012, Josh Boyer wrote:
> >>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
> >>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
> >>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
> >>> >>
> >>> >>     Freeze all filesystems during system suspend and (kernel-driven)
> >>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
> >>> >>     them during the subsequent resume with the help of thaw_supers().
> >>> >>
> >>> >>     This makes filesystems stay in a consistent state in case something
> >>> >>     goes wrong between system suspend (or hibernation) and the subsequent
> >>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
> >>> >>     particular, this should help to solve a long-standing issue that, in
> >>> >>     some cases, during resume from hibernation the boot loader causes the
> >>> >>     journal to be replied for the filesystem containing the kernel image
> >>> >>     and/or initrd causing it to become inconsistent with the information
> >>> >>     stored in the hibernation image.
> >>> >>
> >>> >>     The user-space-driven hibernation (s2disk) is not covered by this
> >>> >>     change, because the freezing of filesystems prevents s2disk from
> >>> >>     accessing device special files it needs to do its job.
> >>> >>
> >>> >>     This change is based on earlier work by Nigel Cunningham.
> >>> >>
> >>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> >>> >>
> >>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
> >>>
> >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> >>> our tree with a comment that says "rebase" and I don't see it in the
> >>> linux-next tree at all.
> >>>
> >>> Did if fall through the cracks or was it NAKed somewhere?
> >>
> >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> >
> > Dredging up a really old thread, sorry.
> >
> > We're still carrying this patch along in Fedora.  Should we drop it at
> > this point, or is it still eventually going to head upstream?
> 
> Fixed Rafael's email address.  (Double sorry.)

No biggie.

I just hadn't got sufficient response for that patch at the time it was
submitted, so I guess it would be good to resubmit it.  Please feel free to
do that if you want.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Josh Boyer]

On Tue, Dec 17, 2013 at 7:52 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, December 17, 2013 11:04:46 AM Josh Boyer wrote:
>> On Tue, Dec 17, 2013 at 11:03 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> On Friday, May 25, 2012, Josh Boyer wrote:
>> >>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
>> >>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
>> >>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
>> >>> >>
>> >>> >>     Freeze all filesystems during system suspend and (kernel-driven)
>> >>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
>> >>> >>     them during the subsequent resume with the help of thaw_supers().
>> >>> >>
>> >>> >>     This makes filesystems stay in a consistent state in case something
>> >>> >>     goes wrong between system suspend (or hibernation) and the subsequent
>> >>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
>> >>> >>     particular, this should help to solve a long-standing issue that, in
>> >>> >>     some cases, during resume from hibernation the boot loader causes the
>> >>> >>     journal to be replied for the filesystem containing the kernel image
>> >>> >>     and/or initrd causing it to become inconsistent with the information
>> >>> >>     stored in the hibernation image.
>> >>> >>
>> >>> >>     The user-space-driven hibernation (s2disk) is not covered by this
>> >>> >>     change, because the freezing of filesystems prevents s2disk from
>> >>> >>     accessing device special files it needs to do its job.
>> >>> >>
>> >>> >>     This change is based on earlier work by Nigel Cunningham.
>> >>> >>
>> >>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>> >>> >>
>> >>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
>> >>>
>> >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
>> >>> our tree with a comment that says "rebase" and I don't see it in the
>> >>> linux-next tree at all.
>> >>>
>> >>> Did if fall through the cracks or was it NAKed somewhere?
>> >>
>> >> No, it wasn't in principle. There were some comments I haven't addressed yet.
>> >
>> > Dredging up a really old thread, sorry.
>> >
>> > We're still carrying this patch along in Fedora.  Should we drop it at
>> > this point, or is it still eventually going to head upstream?
>>
>> Fixed Rafael's email address.  (Double sorry.)
>
> No biggie.
>
> I just hadn't got sufficient response for that patch at the time it was
> submitted, so I guess it would be good to resubmit it.  Please feel free to
> do that if you want.

You want me to resend a patch you authored back to you?  I mean, I can
do that but it seems a bit strange.  All I did was rebase what you
wrote to a newer kernel version.

josh

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Rafael J. Wysocki]

On Tuesday, December 17, 2013 08:00:55 PM Josh Boyer wrote:
> On Tue, Dec 17, 2013 at 7:52 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, December 17, 2013 11:04:46 AM Josh Boyer wrote:
> >> On Tue, Dec 17, 2013 at 11:03 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >> > On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> On Friday, May 25, 2012, Josh Boyer wrote:
> >> >>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
> >> >>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
> >> >>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
> >> >>> >>
> >> >>> >>     Freeze all filesystems during system suspend and (kernel-driven)
> >> >>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
> >> >>> >>     them during the subsequent resume with the help of thaw_supers().
> >> >>> >>
> >> >>> >>     This makes filesystems stay in a consistent state in case something
> >> >>> >>     goes wrong between system suspend (or hibernation) and the subsequent
> >> >>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
> >> >>> >>     particular, this should help to solve a long-standing issue that, in
> >> >>> >>     some cases, during resume from hibernation the boot loader causes the
> >> >>> >>     journal to be replied for the filesystem containing the kernel image
> >> >>> >>     and/or initrd causing it to become inconsistent with the information
> >> >>> >>     stored in the hibernation image.
> >> >>> >>
> >> >>> >>     The user-space-driven hibernation (s2disk) is not covered by this
> >> >>> >>     change, because the freezing of filesystems prevents s2disk from
> >> >>> >>     accessing device special files it needs to do its job.
> >> >>> >>
> >> >>> >>     This change is based on earlier work by Nigel Cunningham.
> >> >>> >>
> >> >>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> >> >>> >>
> >> >>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
> >> >>>
> >> >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> >> >>> our tree with a comment that says "rebase" and I don't see it in the
> >> >>> linux-next tree at all.
> >> >>>
> >> >>> Did if fall through the cracks or was it NAKed somewhere?
> >> >>
> >> >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> >> >
> >> > Dredging up a really old thread, sorry.
> >> >
> >> > We're still carrying this patch along in Fedora.  Should we drop it at
> >> > this point, or is it still eventually going to head upstream?
> >>
> >> Fixed Rafael's email address.  (Double sorry.)
> >
> > No biggie.
> >
> > I just hadn't got sufficient response for that patch at the time it was
> > submitted, so I guess it would be good to resubmit it.  Please feel free to
> > do that if you want.
> 
> You want me to resend a patch you authored back to you?  I mean, I can
> do that but it seems a bit strange.  All I did was rebase what you
> wrote to a newer kernel version.

Well, you can send it to me in private then and I'll resubmit. :-)

I just don't have any recent version of it handy.

Thanks,
Rafael

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Josh Boyer]

On Tue, Dec 17, 2013 at 8:16 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, December 17, 2013 08:00:55 PM Josh Boyer wrote:
>> On Tue, Dec 17, 2013 at 7:52 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Tuesday, December 17, 2013 11:04:46 AM Josh Boyer wrote:
>> >> On Tue, Dec 17, 2013 at 11:03 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >> > On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> >> On Friday, May 25, 2012, Josh Boyer wrote:
>> >> >>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> >> >>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
>> >> >>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
>> >> >>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
>> >> >>> >>
>> >> >>> >>     Freeze all filesystems during system suspend and (kernel-driven)
>> >> >>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
>> >> >>> >>     them during the subsequent resume with the help of thaw_supers().
>> >> >>> >>
>> >> >>> >>     This makes filesystems stay in a consistent state in case something
>> >> >>> >>     goes wrong between system suspend (or hibernation) and the subsequent
>> >> >>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
>> >> >>> >>     particular, this should help to solve a long-standing issue that, in
>> >> >>> >>     some cases, during resume from hibernation the boot loader causes the
>> >> >>> >>     journal to be replied for the filesystem containing the kernel image
>> >> >>> >>     and/or initrd causing it to become inconsistent with the information
>> >> >>> >>     stored in the hibernation image.
>> >> >>> >>
>> >> >>> >>     The user-space-driven hibernation (s2disk) is not covered by this
>> >> >>> >>     change, because the freezing of filesystems prevents s2disk from
>> >> >>> >>     accessing device special files it needs to do its job.
>> >> >>> >>
>> >> >>> >>     This change is based on earlier work by Nigel Cunningham.
>> >> >>> >>
>> >> >>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>> >> >>> >>
>> >> >>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
>> >> >>>
>> >> >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
>> >> >>> our tree with a comment that says "rebase" and I don't see it in the
>> >> >>> linux-next tree at all.
>> >> >>>
>> >> >>> Did if fall through the cracks or was it NAKed somewhere?
>> >> >>
>> >> >> No, it wasn't in principle. There were some comments I haven't addressed yet.
>> >> >
>> >> > Dredging up a really old thread, sorry.
>> >> >
>> >> > We're still carrying this patch along in Fedora.  Should we drop it at
>> >> > this point, or is it still eventually going to head upstream?
>> >>
>> >> Fixed Rafael's email address.  (Double sorry.)
>> >
>> > No biggie.
>> >
>> > I just hadn't got sufficient response for that patch at the time it was
>> > submitted, so I guess it would be good to resubmit it.  Please feel free to
>> > do that if you want.
>>
>> You want me to resend a patch you authored back to you?  I mean, I can
>> do that but it seems a bit strange.  All I did was rebase what you
>> wrote to a newer kernel version.
>
> Well, you can send it to me in private then and I'll resubmit. :-)

Done.  Thanks.

josh

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Dave Chinner]

On Wed, Dec 18, 2013 at 01:01:28AM +0100, Pavel Machek wrote:
> On Wed 2013-12-18 10:31:52, Dave Chinner wrote:
> > On Wed, Dec 18, 2013 at 12:08:43AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> > > > >>> our tree with a comment that says "rebase" and I don't see it in the
> > > > >>> linux-next tree at all.
> > > > >>>
> > > > >>> Did if fall through the cracks or was it NAKed somewhere?
> > > > >>
> > > > >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> > > > >
> > > > > Dredging up a really old thread, sorry.
> > > > >
> > > > > We're still carrying this patch along in Fedora.  Should we drop it at
> > > > > this point, or is it still eventually going to head upstream?
> > > 
> > > I'd say drop.
> > 
> > I disagree - given the problem it is resolving leads to silent
> > filesystem corruption, this patch should be considered somewhat of a
> > priority to push...
> 
> Umm. Ok, I forgot what it does, really.

It ensures that the filesystem is in an quiescent state both in
memory and on disk, and it cannot be modified in memory or on disk
whilst the suspend image is being generated, or by log recovery
after a resume before the suspended image has been restored.

> So... for few years now suspend corrupts data on XFS? And Fedora has
> the fix but it is not in mainline? That does not sound right...

The issues freezing the filesystem before the suspend image is
created affect every journalled filesystem linux supports, be
it XFS, ext4, reiser, btrfs, etc.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Pavel Machek]

> > > I disagree - given the problem it is resolving leads to silent
> > > filesystem corruption, this patch should be considered somewhat of a
> > > priority to push...
> > 
> > Umm. Ok, I forgot what it does, really.
> 
> It ensures that the filesystem is in an quiescent state both in
> memory and on disk, and it cannot be modified in memory or on disk
> whilst the suspend image is being generated, or by log recovery
> after a resume before the suspended image has been restored.

If someone attempts to run log recovery before resume, that's a bug
and yes, it will corrupt filesystems. (Including ext3). Don't do that.

Documentation/power/swsusp.txt:

 * BIG FAT WARNING
   *********************************************************
 *
 * If you touch anything on disk between suspend and resume...
 *                              ...kiss your data goodbye.

> > So... for few years now suspend corrupts data on XFS? And Fedora has
> > the fix but it is not in mainline? That does not sound right...
> 
> The issues freezing the filesystem before the suspend image is
> created affect every journalled filesystem linux supports, be
> it XFS, ext4, reiser, btrfs, etc.

Did not it have some problems with ext3?

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

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Rafael J. Wysocki]

On Wednesday, December 18, 2013 07:31:59 AM Josh Boyer wrote:
> On Tue, Dec 17, 2013 at 8:16 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, December 17, 2013 08:00:55 PM Josh Boyer wrote:
> >> On Tue, Dec 17, 2013 at 7:52 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Tuesday, December 17, 2013 11:04:46 AM Josh Boyer wrote:
> >> >> On Tue, Dec 17, 2013 at 11:03 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >> >> > On Fri, May 25, 2012 at 3:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> >> On Friday, May 25, 2012, Josh Boyer wrote:
> >> >> >>> On Fri, Feb 17, 2012 at 3:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> >> >>> >> commit b94887bbc0621e1e8402e7f0ec4bc3adf46c9a6e
> >> >> >>> >> Author: Rafael J. Wysocki <rjw@sisk.pl>
> >> >> >>> >> Date:   Fri Feb 17 12:42:08 2012 -0500
> >> >> >>> >>
> >> >> >>> >>     Freeze all filesystems during system suspend and (kernel-driven)
> >> >> >>> >>     hibernation by calling freeze_supers() for all superblocks and thaw
> >> >> >>> >>     them during the subsequent resume with the help of thaw_supers().
> >> >> >>> >>
> >> >> >>> >>     This makes filesystems stay in a consistent state in case something
> >> >> >>> >>     goes wrong between system suspend (or hibernation) and the subsequent
> >> >> >>> >>     resume (e.g. journal replays won't be necessary in those cases).  In
> >> >> >>> >>     particular, this should help to solve a long-standing issue that, in
> >> >> >>> >>     some cases, during resume from hibernation the boot loader causes the
> >> >> >>> >>     journal to be replied for the filesystem containing the kernel image
> >> >> >>> >>     and/or initrd causing it to become inconsistent with the information
> >> >> >>> >>     stored in the hibernation image.
> >> >> >>> >>
> >> >> >>> >>     The user-space-driven hibernation (s2disk) is not covered by this
> >> >> >>> >>     change, because the freezing of filesystems prevents s2disk from
> >> >> >>> >>     accessing device special files it needs to do its job.
> >> >> >>> >>
> >> >> >>> >>     This change is based on earlier work by Nigel Cunningham.
> >> >> >>> >>
> >> >> >>> >>     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> >> >> >>> >>
> >> >> >>> >>     Rebased to 3.3-rc3 by Josh Boyer <jwboyer@redhat.com>
> >> >> >>>
> >> >> >>> Did this patch ever wind up going anywhere?  Fedora has it sitting in
> >> >> >>> our tree with a comment that says "rebase" and I don't see it in the
> >> >> >>> linux-next tree at all.
> >> >> >>>
> >> >> >>> Did if fall through the cracks or was it NAKed somewhere?
> >> >> >>
> >> >> >> No, it wasn't in principle. There were some comments I haven't addressed yet.
> >> >> >
> >> >> > Dredging up a really old thread, sorry.
> >> >> >
> >> >> > We're still carrying this patch along in Fedora.  Should we drop it at
> >> >> > this point, or is it still eventually going to head upstream?
> >> >>
> >> >> Fixed Rafael's email address.  (Double sorry.)
> >> >
> >> > No biggie.
> >> >
> >> > I just hadn't got sufficient response for that patch at the time it was
> >> > submitted, so I guess it would be good to resubmit it.  Please feel free to
> >> > do that if you want.
> >>
> >> You want me to resend a patch you authored back to you?  I mean, I can
> >> do that but it seems a bit strange.  All I did was rebase what you
> >> wrote to a newer kernel version.
> >
> > Well, you can send it to me in private then and I'll resubmit. :-)
> 
> Done.  Thanks.

OK, thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Dave Chinner]

On Wed, Dec 18, 2013 at 03:08:42PM +0100, Pavel Machek wrote:
> > > > I disagree - given the problem it is resolving leads to silent
> > > > filesystem corruption, this patch should be considered somewhat of a
> > > > priority to push...
> > > 
> > > Umm. Ok, I forgot what it does, really.
> > 
> > It ensures that the filesystem is in an quiescent state both in
> > memory and on disk, and it cannot be modified in memory or on disk
> > whilst the suspend image is being generated, or by log recovery
> > after a resume before the suspended image has been restored.
> 
> If someone attempts to run log recovery before resume, that's a bug
> and yes, it will corrupt filesystems. (Including ext3). Don't do that.

Freezing the filesystem prevents that accidental mount of the
filesystem from being an issue. It fixes a bug that:

> Documentation/power/swsusp.txt:
> 
>  * BIG FAT WARNING
>    *********************************************************
>  *
>  * If you touch anything on disk between suspend and resume...
>  *                              ...kiss your data goodbye.

Makes this a whole lot less dangerous.

> > > So... for few years now suspend corrupts data on XFS? And Fedora has
> > > the fix but it is not in mainline? That does not sound right...
> > 
> > The issues freezing the filesystem before the suspend image is
> > created affect every journalled filesystem linux supports, be
> > it XFS, ext4, reiser, btrfs, etc.
> 
> Did not it have some problems with ext3?

Please read more carefully: "affect every journalled filesystem
linux supports". So, ext3 is affected because it's a journalling
filesystem.  I didn't list every journalled filesystem Linux
supports - "etc" means there are more examples that aren't
explicitly listed.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Pavel Machek]

Hi!

> > > > > I disagree - given the problem it is resolving leads to silent
> > > > > filesystem corruption, this patch should be considered somewhat of a
> > > > > priority to push...
> > > > 
> > > > Umm. Ok, I forgot what it does, really.
> > > 
> > > It ensures that the filesystem is in an quiescent state both in
> > > memory and on disk, and it cannot be modified in memory or on disk
> > > whilst the suspend image is being generated, or by log recovery
> > > after a resume before the suspended image has been restored.
> > 
> > If someone attempts to run log recovery before resume, that's a bug
> > and yes, it will corrupt filesystems. (Including ext3). Don't do that.
> 
> Freezing the filesystem prevents that accidental mount of the
> filesystem from being an issue. It fixes a bug that:

Can you elaborate on that?

If you do read-write mount of that filesystem, surely filesystem
metadata will differ from what the filesystem expects. You'll still
get data corruption AFAICT.

Read-only mount... maybe that will get slightly better -- there'll be
no journal to play back. But what happens to superblock information
such as "last mount time"? Mount counts?

> > Documentation/power/swsusp.txt:
> > 
> >  * BIG FAT WARNING
> >    *********************************************************
> >  *
> >  * If you touch anything on disk between suspend and resume...
> >  *                              ...kiss your data goodbye.
> 
> Makes this a whole lot less dangerous.

Do you claim that it is now safe to mount (rw) and access filesystem
between suspend and resume?

> > > > So... for few years now suspend corrupts data on XFS? And Fedora has
> > > > the fix but it is not in mainline? That does not sound right...
> > > 
> > > The issues freezing the filesystem before the suspend image is
> > > created affect every journalled filesystem linux supports, be
> > > it XFS, ext4, reiser, btrfs, etc.
> > 
> > Did not it have some problems with ext3?
> 
> Please read more carefully: "affect every journalled filesystem
> linux supports". So, ext3 is affected because it's a journalling
> filesystem.  I didn't list every journalled filesystem Linux
> supports - "etc" means there are more examples that aren't
> explicitly listed.

Sorry for being unclear. My memory says this patch caused some
regression with ext3. Is my memory wrong? Or was the regression fixed
in the meantime?

(Clearly, ext3 has the same issues with journal replays as btrfs. But
note that mounting filesystem between suspend and resume is not safe
even on simple filesystems such as ext2).

Thanks,
								Pavel

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

Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

[Dave Chinner]

On Sun, Dec 22, 2013 at 12:33:18AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > I disagree - given the problem it is resolving leads to silent
> > > > > > filesystem corruption, this patch should be considered somewhat of a
> > > > > > priority to push...
> > > > > 
> > > > > Umm. Ok, I forgot what it does, really.
> > > > 
> > > > It ensures that the filesystem is in an quiescent state both in
> > > > memory and on disk, and it cannot be modified in memory or on disk
> > > > whilst the suspend image is being generated, or by log recovery
> > > > after a resume before the suspended image has been restored.
> > > 
> > > If someone attempts to run log recovery before resume, that's a bug
> > > and yes, it will corrupt filesystems. (Including ext3). Don't do that.
> > 
> > Freezing the filesystem prevents that accidental mount of the
> > filesystem from being an issue. It fixes a bug that:
> 
> Can you elaborate on that?
> 
> If you do read-write mount of that filesystem, surely filesystem
> metadata will differ from what the filesystem expects. You'll still
> get data corruption AFAICT.

Only if you modify stuff. That's not what we are protecting against,
it's avoiding the automatic journal replay that you can't avoid if
you accidentally mount the filesystem.

> Read-only mount... maybe that will get slightly better -- there'll be
> no journal to play back. But what happens to superblock information
> such as "last mount time"? Mount counts?

If metadata is being modified on a read only mount outside of
journal replay, then the filesystem needs fixing.

> 
> > > Documentation/power/swsusp.txt:
> > > 
> > >  * BIG FAT WARNING
> > >    *********************************************************
> > >  *
> > >  * If you touch anything on disk between suspend and resume...
> > >  *                              ...kiss your data goodbye.
> > 
> > Makes this a whole lot less dangerous.
> 
> Do you claim that it is now safe to mount (rw) and access filesystem
> between suspend and resume?

No, I didn't claim that. "less dangerous" is still dangerous, just
less so than it was before.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com