Re: [linux-pm] [RFC] why do we need run disk sync before entering S3

["Rafael J. Wysocki" <rjw@sisk.pl>]

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