Messages in this thread |  | | Date | Sat, 29 Sep 2001 10:40:27 +0200 | From | Pavel Machek <> | Subject | Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9] |
| |
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. - 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/
|  |