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

Pavel Machek (pavel@suse.cz)
Sat, 29 Sep 2001 10:40:27 +0200


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/