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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 13 May 2009, Alan Stern wrote:
> On Wed, 13 May 2009, Rafael J. Wysocki wrote:
> 
> > > > I generally agree, but I think we may also leave the syncing to the user space,
> > > > in both cases.
> > > 
> > > Well...
> > > 
> > > Normally kernel writes dirty data to disk each 30
> > > seconds. s2ram/s2disk breaks that promise, so it seems fair to add
> > > explicit sync to keep the "promise".
> > > 
> > > OTOH, I agree it would be more flexible if we left sync to
> > > userspace. In uswsusp case, it actually makes sense. In s2ram
> > > case... if we can do it while keeping compatibility with old
> > > behaviour... why not.
> > 
> > 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. :-)

Thanks,
Rafael
--
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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux