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. > > How can you say it's only required for niceness one minute, then admit > it might result in data loss the next?
It will result in data loss *if resume fails*. But failing resume *always* causes data in running programs to be lost, so I do not see that as a problem. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/