> > > That really depends on the distrubution. (open)SUSE always syncs before > > > suspend/hibernation AFAICS, but I don't know about the other distros. > > > > This doesn't address the real question: Should the system be allowed to > > go into S3 without doing a sync first? > > > > Whether the sync is initiated by userspace or by the kernel doesn't > > make any difference. Likewise, it doesn't matter if there are two > > syncs (because the second will be very fast, as Pavel said). > > > > If you really wanted to speed up the suspend transition then you would > > leave out the sync entirely. But IMO this would be a mistake; the risk > > of data loss is too great. Which means the time overhead is necessary, > > one way or another. If userspace does a sync first then the suspend > > transition will be faster, but this is just an accounting artifact (do > > you count the time required for the sync toward the time required for > > the suspend or not). > > My point was in fact that if we left the syncing to the user space, then the > user would be able to decide not to sync risking data loss. At the moment the > user has no choice. :-) Well, if you can add the choice, without adding anything ugly and with staying back-compatible, why not. (sync has to stay by default). I believe ioctls() on /dev/snapshot may already enable you to do s2ram without sync; if not they could be extended. But remember there are even in-kernel s2ram triggers, for example on zaurus when battery goes critical. (And s2ram without sync _is_ "wrong": writeback timeouts are not honored). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
