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

Albert D. Cahalan
2001-09-28T03:56:01Z

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.