From: Pavel Machek <pavel@suse.cz>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]
Date: Fri, 28 Sep 2001 22:40:01 +0200 [thread overview]
Message-ID: <20010928224001.B1100@bug.ucw.cz> (raw)
In-Reply-To: <20010927163421.C23647@atrey.karlin.mff.cuni.cz> <200109280356.f8S3u5g154813@saturn.cs.uml.edu>
In-Reply-To: <200109280356.f8S3u5g154813@saturn.cs.uml.edu>; from Albert D. Cahalan on Thu, Sep 27, 2001 at 11:56:05PM -0400
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
next prev parent reply other threads:[~2001-09-28 20:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2001-09-29 7:55 ` Albert D. Cahalan
2001-09-29 8:40 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010928224001.B1100@bug.ucw.cz \
--to=pavel@suse.cz \
--cc=acahalan@cs.uml.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox