[lkml]   [2001]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

> > [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.
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.058 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site