Hi. On Tue, 2005-07-12 at 20:57, Pavel Machek wrote: > 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'. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. Be amazed that people believe it happened. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
