Well, as far as Suspend can see, all the data has been written. By the
time we reach this point, the end_buffer_io_async routine has been
called for every write submitted, and the last write submitted by
anything else was at least a few seconds ago (all other processes are
frozen and drivers suspended), so all data _should_ be on disk already
and sync should do nothing. Actually, we wouldn't want to call sync
anyway for reasons I won't go into here (unnecessary complication). I'm
sure you'd agree that we would want to delay for an arbitrary length of
time either (no guarantees that that would cut the mustard). We need to
flush caches properly.

Regards,

Nigel

On Fri, 2004-01-23 at 08:19, James H. Cloos Jr. wrote:
> John> I think it is an attempt to force some broken drives to flush
> John> their cache, but I wonder whether it will simply move the
> John> problem from one set of broken drives to another :-).
> 
> It will.  I've had to work with a few drives or drive combos over
> the years that would not spin up reliably.  It was vital to keep
> them spinning once they were (all) up.  Adding this would make
> reboot unnecessarily unuseable in such cases.  Perhaps just
> flush, pause, flush would work as well?
> 
> Or even the logical equivilent to sync;sync;sync;reboot?
> 
> -JimC
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.