Re: Back to the future.

[Nigel Cunningham]

Hi.

On Thu, 2007-04-26 at 10:34 -0700, Linus Torvalds wrote:
> 
> On Thu, 26 Apr 2007, Xavier Bestel wrote:
> > 
> > Won't there be problems if e.g. X tries to write something to its
> > logfile after snapshot ?
> 
> Sure. But that's a user-level issue.
> 
> You do have to allow writing after snapshotting, since at a minimum, you'd 
> want the snapshot itself to be written. So the kernel has to be fully 
> running, and support full user space. No "degraded mode" like now.

It doesn't need a fully functional userspace (unless you want to write
to a fuse device, and even then that could be worked around - make it
like uswsusp or userui).... can I deverge for a second and say that from
this point of view, fuse is the lamest idea ever invented. Guaranteed to
break your ability to suspend^Wsnapshot.... Anyhow, if the kernel has
bmapped the pages it's going to write to beforehand, it knows where the
image needs to go. No need for userspace at all.

> So when I said "fully running user mode", I really meant it from the 
> perspective of the kernel - not necessarily from the perspective of the 
> "user". You do want to limit _what_ user mode does, but you must not limit 
> it by making the kernel less capable.
> 
> Remounting mounted filesystems read-only sounds like a good idea, for 
> example. We can do that. We have the technology. But we shouldn't limit 
> user space from doing other things (for example, it might want to actually 
> *mount* a new filesystem for writing the snapshot image).

We tried that. It would need some work. IIRC remounting filesystems
read-only makes files become marked read-only. Perfectly sensible,
except that if you then remount the filesystem rw at resume time, all
those files are still marked ro and userspace crashes and burns. Not
unfixable, I'll agree, but there is more work to do there.

As to the example, mounting a new filesystem for writing the snapshot
image should probably be done before we do the snapshot. Then it won't
be in danger of triggering anything that might require one of the other
fses to be rw (eg syslog).

> For example, right now we try to "fix" that with the whole process freezer 
> thing. And that code has *caused* more problems than it fixed, since it 
> tries to freeze all the kernel threads etc, and you simply don't have a 
> truly *working*system*.

Yes, it has been difficult. But so is bringing up a child.

> I think it's fine to freeze processes if that is what you want to do (for 
> example, send them SIGSTOP), but we freeze them *too*much* right now, and 
> the suspend stuff has taken over policy way too much. We don't actually 
> leave the system in a runnable state. I can almost guarantee that you'd be 
> *better* off having the snapshot taking thing do a
> 
> 	kill(-1, SIGSTOP);
> 
> in user space than our current broken process freezer. At least that 
> wouldn't have screwed up those kernel threads as badly as swsusp did.

I don't think it's fair to blame swsusp there. Maybe cpu hotplugging...

> And no, I'm not saying that my suggestion is the only way to do it. Go 
> wild. But the *current* situation is just broken. Three different things, 
> none of which people can agree on. I'd *much* rather see a conceptually 
> simpler approach that then required, but even more important is that right 
> now people aren't even discussing alternatives, they're just pushing one 
> of the three existing things, and that's simply not viable. Because I'm 
> not merging another one.
> 
> In fact, I personally feel that I shouldn't even have merged 
> userspace-swsusp, but if Andrew thinks it needs to be merged, my personal 
> feelings simply don't matter that much. I have to trust people. But yes, 
> as far as *I* am personally concerned, I think it was a mistake to merge 
> it.

Perhaps you should try to make an alternative yourself instead of
pushing us into making something we don't believe will work (my case) or
have already done but in a way you don't like (Rafael). Don't talk about
Pavel cutting code. He's just acking/nacking what Rafael sends him.

Nigel

Attachment: signature.asc
Description: This is a digitally signed message part