Hi. On Fri, 2005-07-22 at 01:39, Pavel Machek wrote: > Hi! > > > This patch implements a new PF_SYNCTHREAD flag, which allows upcoming > > the refrigerator implementation to know that a thread is syncing data to > > disk. This allows the refrigerator to be more reliable, even under heavy > > load, because it can separate userspace processes that are submitting > > I/O from those trying to sync it and freezing the former first. We can > > thus ensure that syncing processes complete their work more quickly and > > the refrigerator is far less likely to incorrectly give up (thinking a > > syncing process is completely failing to enter the refrigerator). > > This patch is ****, and pretty intrusive too. Ouch and then it is > unneccessary. We have been over this before, and explained to you in > person. Greg explained it to you, too. This one is NOT GOING IN. Drop > it from your patches, trying to submit it 10 times will not get it > accepted. > > [For the record, simple solution for this one is > > sys_sync(); > > and only then start refrigeration]. That's not right. Greg said he believed the right thing to do was to sync in the kernel, but he also said he agreed with you. I thought at the time he was confused about who was suggesting what - let's check with him. Anyway, we discussed before that sync_sync before starting refrigerating is insufficient. Remember that since processes aren't refrigerated yet, there is absolutely nothing to stop other processes submitting I/O between the two actions and thus making the sync pointless. The sync needs to be done after the userspace processes that might submit I/O have been frozen, to ensure that all the dirty data is actually synced to disk. Remember also that it is important that we do need to sync all dirty buffers. In the case of not resuming, data loss should nil. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities.
