LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* swsusp: move resume before mounting root [diff against vanilla 2.4.9]
@ 2001-09-18 16:42 Pavel Machek
       [not found] ` <200109260602.f8Q62TM420328@saturn.cs.uml.edu>
  0 siblings, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2001-09-18 16:42 UTC (permalink / raw)
  To: swsusp, seasons; +Cc: kernel list

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

Hi!

This is my latest version of swsusp relative to linus' 2.4.9, just in
case someone wants to try it... It should now be compatible with
reiserfs.

Note: it does rather ugly trick with signals (all recent versions
do). That will need to be fixed, somehow.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

[-- Attachment #2: delme.gz --]
[-- Type: application/octet-stream, Size: 13480 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
       [not found] ` <200109260602.f8Q62TM420328@saturn.cs.uml.edu>
@ 2001-09-26  8:19   ` Pavel Machek
  2001-09-27  3:02     ` Albert D. Cahalan
  0 siblings, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2001-09-26  8:19 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: kernel list

Hi!

> Solution for the filesystem problems:
> 
> 1. at suspend, basically unmount the filesystem (keep the mount tree)
> 2. at resume, re-validate open files

Wrong solution. ;-).

Solution to filesystem problems: at suspend, sync but don't do
anything more. At resume, don't try to mount anything (so that you
don't replay transactions or damage disk in any other way).
					Pavel



-- 
Causalities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-26  8:19   ` Pavel Machek
@ 2001-09-27  3:02     ` Albert D. Cahalan
  2001-09-27  4:29       ` Andreas Dilger
                         ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Albert D. Cahalan @ 2001-09-27  3:02 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Albert D. Cahalan, kernel list

Pavel Machek writes:
> [Albert Cahalan]

>> Solution for the filesystem problems:
>>
>> 1. at suspend, basically unmount the filesystem (keep the mount tree)
>> 2. at resume, re-validate open files
>
> Wrong solution. ;-).
>
> Solution to filesystem problems: at suspend, sync but don't do
> anything more. At resume, don't try to mount anything (so that you
> don't replay transactions or damage disk in any other way).

That is totally broken, because I may mount the disk in between
the suspend and resume. I might even:

1. boot kernel X
2. suspend kernel X
3. boot kernel Y
4. suspend kernel Y
5. resume kernel X
6. suspend kernel X
7. resume kernel Y
8. suspend kernel Y
9. goto #5

You really have to close the logs and mark the disks clean
when you suspend. The problems here are similar the the ones
NFS faces. Between the suspend and resume, filesystems may be
modified in arbitrary ways.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-27  3:02     ` Albert D. Cahalan
@ 2001-09-27  4:29       ` Andreas Dilger
  2001-09-27  4:51       ` Tim Connors
  2001-09-27 14:34       ` swsusp: move " Pavel Machek
  2 siblings, 0 replies; 11+ messages in thread
From: Andreas Dilger @ 2001-09-27  4:29 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: Pavel Machek, kernel list

On Sep 26, 2001  23:02 -0400, Albert D. Cahalan wrote:
> That is totally broken, because I may mount the disk in between
> the suspend and resume. I might even:
> 
> 1. boot kernel X
> 2. suspend kernel X
> 3. boot kernel Y
> 4. suspend kernel Y
> 5. resume kernel X
> 6. suspend kernel X
> 7. resume kernel Y
> 8. suspend kernel Y
> 9. goto #5
> 
> You really have to close the logs and mark the disks clean
> when you suspend. The problems here are similar the the ones
> NFS faces. Between the suspend and resume, filesystems may be
> modified in arbitrary ways.

This is possible with the "write_super_lockfs" interface to the
journaling filesystems (ext3/reiserfs/XFS).  This is normally
used for LVM snapshots, but it could also be used for this.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert


^ permalink raw reply	[flat|nested] 11+ messages in thread

* resume before mounting root [diff against vanilla 2.4.9]
  2001-09-27  3:02     ` Albert D. Cahalan
  2001-09-27  4:29       ` Andreas Dilger
@ 2001-09-27  4:51       ` Tim Connors
  2001-09-29 22:23         ` Pavel Machek
  2001-09-27 14:34       ` swsusp: move " Pavel Machek
  2 siblings, 1 reply; 11+ messages in thread
From: Tim Connors @ 2001-09-27  4:51 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: Pavel Machek, kernel list

On Wed, 26 Sep 2001, Albert D. Cahalan wrote:

> Pavel Machek writes:
> > [Albert Cahalan]
> 
> >> Solution for the filesystem problems:
> >>
> >> 1. at suspend, basically unmount the filesystem (keep the mount tree)
> >> 2. at resume, re-validate open files
> >
> > Wrong solution. ;-).
> >
> > Solution to filesystem problems: at suspend, sync but don't do
> > anything more. At resume, don't try to mount anything (so that you
> > don't replay transactions or damage disk in any other way).
> 
> That is totally broken, because I may mount the disk in between
> the suspend and resume. I might even:
> 
> 1. boot kernel X
> 2. suspend kernel X
> 3. boot kernel Y
> 4. suspend kernel Y
> 5. resume kernel X
> 6. suspend kernel X
> 7. resume kernel Y
> 8. suspend kernel Y
> 9. goto #5
> 
> You really have to close the logs and mark the disks clean
> when you suspend. The problems here are similar the the ones
> NFS faces. Between the suspend and resume, filesystems may be
> modified in arbitrary ways.

I missed the rest of the thread, but if you are talking about what I think
you are talking about, I'll go <AOL>Me too</AOL>

A horrible combination of accidents with scripts that set lilo to boot
to the hibernated partition if last suspended, and an apparent BIOS bug
that allowed me to boot out of a hibernated partition for a second
time meant that my laptop came out of regular hibernation mode (as
opposed to using swsusp for "hibernation") 2 months
after I originally suspended the machine. After I had gone through
numerous kernel upgrades and reboots, and after I had partially
repartioned the drive. Needless to say, there were a number of partitions
that were toast after this issue. Fortunately, I had made a backup of my
drive (including me thesis!) only a week beforehand, and /home was fine.
Not bad concidering the last backup was from 3 months ago!


-- 
TimC -- http://www.physics.usyd.edu.au/~tcon/

This is a dirty hack!  It might burn your PC and kill your cat!
  -- mpg123.c source



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-27  3:02     ` Albert D. Cahalan
  2001-09-27  4:29       ` Andreas Dilger
  2001-09-27  4:51       ` Tim Connors
@ 2001-09-27 14:34       ` Pavel Machek
  2001-09-28  3:56         ` Albert D. Cahalan
  2 siblings, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2001-09-27 14:34 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: kernel list

Hi!

> >> Solution for the filesystem problems:
> >>
> >> 1. at suspend, basically unmount the filesystem (keep the mount tree)
> >> 2. at resume, re-validate open files
> >
> > Wrong solution. ;-).
> >
> > Solution to filesystem problems: at suspend, sync but don't do
> > anything more. At resume, don't try to mount anything (so that you
> > don't replay transactions or damage disk in any other way).
> 
> That is totally broken, because I may mount the disk in between
> the suspend and resume. I might even:
> 
> 1. boot kernel X
> 2. suspend kernel X
> 3. boot kernel Y
> 4. suspend kernel Y
> 5. resume kernel X
> 6. suspend kernel X
> 7. resume kernel Y
> 8. suspend kernel Y
> 9. goto #5
> 
> You really have to close the logs and mark the disks clean
> when you suspend. The problems here are similar the the ones

I can't do that: open deleted files.

> NFS faces. Between the suspend and resume, filesystems may be
> modified in arbitrary ways.

No, you don't want to do that. This is swsusp package, meant to
replace suspend-to-disk on your notebook. If you choose random
notebook, it will allow you to suspend to disk, but not to suspend,
boot X, poweron, boot Y, reboot, boot X.

If you do what you described, you'll corrupt your filesystem. It is
designed that way.
								Pavel
-- 
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-27 14:34       ` swsusp: move " Pavel Machek
@ 2001-09-28  3:56         ` Albert D. Cahalan
  2001-09-28 20:40           ` Pavel Machek
  0 siblings, 1 reply; 11+ messages in thread
From: Albert D. Cahalan @ 2001-09-28  3:56 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Albert D. Cahalan, kernel list

Pavel Machek writes:

>>>> Solution for the filesystem problems:
>>>>
>>>> 1. at suspend, basically unmount the filesystem (keep the mount tree)
>>>> 2. at resume, re-validate open files
>>>
>>> Wrong solution. ;-).
>>>
>>> Solution to filesystem problems: at suspend, sync but don't do
>>> anything more. At resume, don't try to mount anything (so that you
>>> don't replay transactions or damage disk in any other way).
>>
>> That is totally broken, because I may mount the disk in between
>> the suspend and resume. I might even:
>>
>> 1. boot kernel X
>> 2. suspend kernel X
>> 3. boot kernel Y
>> 4. suspend kernel Y
>> 5. resume kernel X
>> 6. suspend kernel X
>> 7. resume kernel Y
>> 8. suspend kernel Y
>> 9. goto #5
>>
>> You really have to close the logs and mark the disks clean
>> when you suspend. The problems here are similar the the ones
>
> I can't do that: open deleted files.

Tough luck. Either use the same hack as NFS, or have such files
return -EIO for all operations and give SIGBUS for mappings.
Maybe just refuse to suspend when there are open deleted files.
Oh, just create a name in the filesystem root and use that.
Something like ".8fe4a979.swsusp" would be fine. Whatever!

>> NFS faces. Between the suspend and resume, filesystems may be
>> modified in arbitrary ways.
>
> No, you don't want to do that. This is swsusp package, meant to
> replace suspend-to-disk on your notebook. If you choose random
> notebook, it will allow you to suspend to disk, but not to suspend,
> boot X, poweron, boot Y, reboot, boot X.
>
> If you do what you described, you'll corrupt your filesystem. It is
> designed that way.

Not "If", but "When". Somebody has already posted a report of
doing exactly that, by accident, with a 3-month-old suspension.
The filesystems were destroyed.

Right now, swsusp is a serious hazard.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-28  3:56         ` Albert D. Cahalan
@ 2001-09-28 20:40           ` Pavel Machek
  2001-09-29  7:55             ` Albert D. Cahalan
  0 siblings, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2001-09-28 20:40 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: kernel list

Hi!

> > I can't do that: open deleted files.
> 
> Tough luck. Either use the same hack as NFS, or have such files
> return -EIO for all operations and give SIGBUS for mappings.
> Maybe just refuse to suspend when there are open deleted files.
> Oh, just create a name in the filesystem root and use that.
> Something like ".8fe4a979.swsusp" would be fine. Whatever!

...and break locking and similar stuff. NFS is not as good as local
filesystem.

> >> NFS faces. Between the suspend and resume, filesystems may be
> >> modified in arbitrary ways.
> >
> > No, you don't want to do that. This is swsusp package, meant to
> > replace suspend-to-disk on your notebook. If you choose random
> > notebook, it will allow you to suspend to disk, but not to suspend,
> > boot X, poweron, boot Y, reboot, boot X.
> >
> > If you do what you described, you'll corrupt your filesystem. It is
> > designed that way.
> 
> Not "If", but "When". Somebody has already posted a report of
> doing exactly that, by accident, with a 3-month-old suspension.
> The filesystems were destroyed.
> 
> Right now, swsusp is a serious hazard.

That's why its called experimental ;-).

Currently we have "SWSUSP" signature, SWAP-FILE gets replaced with
SWSUSP on suspend, and SWAP-FILE is written back on resume. That way,
you can not resume two times from one image.

Additional safety measure could be added: on every swapon, check if
"SWSUSP" is there, and replace it with "SWAP-FILE" if so. (Currently
it says -EINVAL). That should make it pretty safe.

Of course, you'll still be able to shoot yourself in the foot even
with added "security". Just don't do it, then.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-28 20:40           ` Pavel Machek
@ 2001-09-29  7:55             ` Albert D. Cahalan
  2001-09-29  8:40               ` Pavel Machek
  0 siblings, 1 reply; 11+ messages in thread
From: Albert D. Cahalan @ 2001-09-29  7:55 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Albert D. Cahalan, kernel list

Pavel Machek writes:
> [Albert Cahalan]
>> [Pavel Machek]

>>> I can't do that: open deleted files.
>>
>> Tough luck. Either use the same hack as NFS, or have such files
>> return -EIO for all operations and give SIGBUS for mappings.
>> Maybe just refuse to suspend when there are open deleted files.
>> Oh, just create a name in the filesystem root and use that.
>> Something like ".8fe4a979.swsusp" would be fine. Whatever!
>
> ...and break locking and similar stuff. NFS is not as good as local
> filesystem.

Oh well. Network connections die and real-time apps fail too.
It is important to have safe and useful behavior in the presence
of arbitrary filesystem modifications. It is very nice to be able
to use suspend/resume to alternate between two running kernels.

I wouldn't worry about locking. Write/discard all data on suspend,
then examine the inode on resume. As long as the inode doesn't
change by more than the atime, the lock can survive.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
  2001-09-29  7:55             ` Albert D. Cahalan
@ 2001-09-29  8:40               ` Pavel Machek
  0 siblings, 0 replies; 11+ messages in thread
From: Pavel Machek @ 2001-09-29  8:40 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: kernel list

Hi!

> > [Albert Cahalan]
> >> [Pavel Machek]
> 
> >>> I can't do that: open deleted files.
> >>
> >> Tough luck. Either use the same hack as NFS, or have such files
> >> return -EIO for all operations and give SIGBUS for mappings.
> >> Maybe just refuse to suspend when there are open deleted files.
> >> Oh, just create a name in the filesystem root and use that.
> >> Something like ".8fe4a979.swsusp" would be fine. Whatever!
> >
> > ...and break locking and similar stuff. NFS is not as good as local
> > filesystem.
> 
> Oh well. Network connections die and real-time apps fail too.
> It is important to have safe and useful behavior in the presence
> of arbitrary filesystem modifications. It is very nice to be able
> to use suspend/resume to alternate between two running kernels.
> 
> I wouldn't worry about locking. Write/discard all data on suspend,
> then examine the inode on resume. As long as the inode doesn't
> change by more than the atime, the lock can survive.

And if did? So now semantics is "it somehow works in presence of FS
modifications, but not completely"?

I look at it this way: ability to survive filesystem modifications
would be nice, but it is quite hard to do. (Probably bigger diff than
what I have, now.)

Admitedly, it would also be nice to be able for kernel *to survive
arbitrary fs modifications without suspend-to-disk* -- imagine two
machines sharing one SCSI disk. No other suspend-to-disk
implementation I know of does what you describe. So I treat problems
orthogonal. What you want is usefull (you can do forced unmount that
way), but it is not required for software suspend.
							Pavel
-- 
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: resume before mounting root [diff against vanilla 2.4.9]
  2001-09-27  4:51       ` Tim Connors
@ 2001-09-29 22:23         ` Pavel Machek
  0 siblings, 0 replies; 11+ messages in thread
From: Pavel Machek @ 2001-09-29 22:23 UTC (permalink / raw)
  To: Tim Connors, Albert D. Cahalan; +Cc: kernel list

Hi!

> > That is totally broken, because I may mount the disk in between
> > the suspend and resume. I might even:
> > 
> > 1. boot kernel X
> > 2. suspend kernel X
> > 3. boot kernel Y
> > 4. suspend kernel Y
> > 5. resume kernel X
> > 6. suspend kernel X
> > 7. resume kernel Y
> > 8. suspend kernel Y
> > 9. goto #5
> > 
> > You really have to close the logs and mark the disks clean
> > when you suspend. The problems here are similar the the ones
> > NFS faces. Between the suspend and resume, filesystems may be
> > modified in arbitrary ways.
> 
> I missed the rest of the thread, but if you are talking about what I think
> you are talking about, I'll go <AOL>Me too</AOL>
> 
> A horrible combination of accidents with scripts that set lilo to boot
> to the hibernated partition if last suspended, and an apparent BIOS bug
> that allowed me to boot out of a hibernated partition for a second
> time meant that my laptop came out of regular hibernation mode (as

swsusp code will not allow you to restore from one partition twice.

								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2001-09-30 18:25 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-18 16:42 swsusp: move resume before mounting root [diff against vanilla 2.4.9] Pavel Machek
     [not found] ` <200109260602.f8Q62TM420328@saturn.cs.uml.edu>
2001-09-26  8:19   ` Pavel Machek
2001-09-27  3:02     ` Albert D. Cahalan
2001-09-27  4:29       ` Andreas Dilger
2001-09-27  4:51       ` Tim Connors
2001-09-29 22:23         ` Pavel Machek
2001-09-27 14:34       ` swsusp: move " Pavel Machek
2001-09-28  3:56         ` Albert D. Cahalan
2001-09-28 20:40           ` Pavel Machek
2001-09-29  7:55             ` Albert D. Cahalan
2001-09-29  8:40               ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).