swsusp: move resume before mounting root [diff against vanilla 2.4.9]

swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Pavel Machek]

[-- 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 --]

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Pavel Machek]

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.

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Albert D. Cahalan]

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.

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Andreas Dilger]

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

resume before mounting root [diff against vanilla 2.4.9]

[Tim Connors]

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

Re: resume before mounting root [diff against vanilla 2.4.9]

[Pavel Machek]

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

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Pavel Machek]

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.

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Albert D. Cahalan]

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.

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Pavel Machek]

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

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Albert D. Cahalan]

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.

Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

[Pavel Machek]

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.