Re: [PATCH] [5/48] Suspend2 2.1.9.8 for 2.6.12: 350-workthreads.patch

[Pavel Machek]

Hi!

> > > > Again, why do you think you need this?
> > > 
> > > 1. If something should be wrong with the freezer, it forms part of a
> > > safety net that stops your data on disk being trashed.
> > 
> > > 2. Separating out threads doing syncing from threads submitting I/O
> > > makes the refrigerator much more reliable, even under extreme load.
> > 
> > This seems to be red herring. Sometimes sync took way too long (like
> > hours) with older kernels and reiserfs, but I believe that has been
> > fixed. If not, we need to fix it, anyway; no need to work around it in
> > suspend2.
> 
> Are you considering races such as the case where one process is
> submitting I/O (say dd) while another is trying to sync? Even if sync
> does return sooner (presumably because it only syncs writes submitted
> before the sync), there will still be dirty data after the sync
> completes. And if we start another sync thread, it will suffer the same
> problem. The only solution is to stop I/O being submitted, then sync.
> But having stopped I/O being submitted, we need to still have the
> threads the process the I/O (possibly userspace ones) unfrozen. Hence we
> need to differentiate 'syncthreads'.

OTOH: this is only critical for "niceness", not for
correctness. Calling sync() before suspend is simply nice thing to do,
but it is not required in any way. If someone is doing long dd, tough,
they are going to loose some data if wakeup fails. It is no worse than
sudden poweroff.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/