On Wed, Nov 23, 2011 at 12:29:48PM -0800, Andrew Morton wrote: > > Still, if it's ***only*** for SIGKILL, we'll probably be OK, since > > for that one case there's no chance userspace can intercept the signal, > > so it can't do any recovery anyway. (I could imagine some HPC program > > doing a massive 2GB write, and some user of that program depending on > > the fact that he can kill it at a predefined place by sending a SIGKILL > > and knowing that the file would be written up to that 2GB chunk --- but > > that's clearly an edge situation, as opposed to something that would > > effect most GNOME and KDE apps.) We just need to make sure we never try > > to do this for any other signal that could be caught, such as SIGINT or > > SIGQUIT or (worse yet) SIGTSTP. > > That it is a fatal SIGKILL means that the *current* application doesn't > care. But other processes will sometimes notice this change. > Previously if an app did write(file, 128k) and was hit with SIGKILL, it > would write either 0 bytes or 128k bytes. Now, it can write 36k bytes, > yes? If the target file consisted of a stream of 128k records then the > user will claim, with some justification, that Linux corrupted it. On the other hand, if there was a crash mid-write, they might also get a 36k write that actually hit media (right? Or do we guarantee that on reboot you see a multiple of 128k?) We could put in some nice code that rewinds i_size to where it used to be if the write was interrupted. Or do we need to? Presumably write_end would not have been called, so i_size would not have been updated. > Dunno. People do lots of weird and flakey things. I have a suspicion > that we'll be hearing back from them about this change. The problem is that we may not hear from them for 6 years ... or whenever they decide to move off RHEL 3. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
