Recent Features
| |||||||||||||
Now what about shutdown?Now what about shutdown?Posted Sep 25, 2008 15:13 UTC (Thu) by dmarti (subscriber, #11625)In reply to: Now what about shutdown? by arjan Parent article: LPC: Booting Linux in five seconds If the app really needed that data it would have called fsync a while ago -- so just halt. Applications are going to have to be able to handle coming back after a kernel panic or a kicked-out power cord anyway.
(Log in to post comments)
Now what about shutdown? Posted Sep 26, 2008 2:24 UTC (Fri) by njs (guest, #40338) [Link]
Uh... so if I hit "save" while using my app, that app should always fsync before returning? That sounds awful. (I guess the alternative is that we just throw away the files that users thought they had saved, but that seems suboptimal.)
IIRC emacs (used to?) do this by default, and until I disabled that it was unusable on a laptop, because hitting C-x C-s blocked everything for a few seconds waiting for the drive to spin up. ELISP SMASH
When is "save" really "maybe save"? Posted Sep 26, 2008 15:05 UTC (Fri) by dmarti (subscriber, #11625) [Link] Applications could be smart about this. The answer might be something like: fsync on save if 100 user actions or 10s of CPU time have been spent on the file since the last save. Or fsync on save if the file has gone from a broken state (invalid HTML, spelling errors, audio that clips, program that won't compile) to a fixed state.(And you could always do the fsync in a separate thread or process, so the app is responsive again.)
When is "save" really "maybe save"? Posted Sep 26, 2008 21:43 UTC (Fri) by njs (guest, #40338) [Link]
fsync doesn't mean "hey kernel actually write this to disk", it means "write this to disk *now*" (and in practice, "write everything to disk *now*", because our filesystems are not that great). If you're running it async, then you get exactly the same semantics as a plain write. The kernel already guarantees that stuff will be written to disk within n seconds, with n a tweakable parameter that's important for power saving. I guess I just don't see the advantages of moving that to a million per-app settings, all using an inappropriate interface.
If the goal is to reach a point where we can throw away a lot of data instead of flushing it to disk at shutdown, then this approach is making a classic mistake: it's trying to mark everything that *does* need to go to disk, and hoping that eventually everything will be marked and we'll be able to flip the switch and throw everything else away. The better approach is to mark stuff that isn't important, like some fcntl to request "power-loss semantics" for writes to some file; then you could get some win immediately, and expand it incrementally over time.
I doubt this is easy or important enough to actually get the coordinated effort needed to implement it, but that's how I'd do it...
|
|||||||||||||