Messages in this thread |  | | Date | Fri, 28 Sep 2001 22:40:01 +0200 | From | Pavel Machek <> | Subject | Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9] |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |