Re: [PATCH 2/2] Make write(2) interruptible by a signal

[Jan Kara <jack@suse.cz>]

On Thu 24-11-11 12:27:11, Matthew Wilcox wrote:
> 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?)
  They might see only 36k written for all filesystems I know...

> 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.
  But that would solve only extending writes and not overwrites. So I'm not
sure it would be worth it...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR