On Thursday 14 May 2009, Pavel Machek wrote: > > > > > 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). OK, so I think the answer is we need the sync() as long as our filesystems don't support suspend-resume directly. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
