From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 2/2] Make write(2) interruptible by a signal Date: Thu, 24 Nov 2011 21:53:45 +0100 Message-ID: <20111124205345.GC29519@quack.suse.cz> References: <1321441935-6802-1-git-send-email-jack@suse.cz> <1321441935-6802-3-git-send-email-jack@suse.cz> <20111116114421.GA9098@localhost> <20111122142805.4e59faae.akpm@linux-foundation.org> <20111123090533.GA22420@localhost> <20111123015005.8f366566.akpm@linux-foundation.org> <20111123122948.4aa7ddfa.akpm@linux-foundation.org> <20111124192711.GM4387@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , Theodore Tso , Wu Fengguang , Jan Kara , Christoph Hellwig , Al Viro , "linux-fsdevel@vger.kernel.org" To: Matthew Wilcox Return-path: Received: from cantor2.suse.de ([195.135.220.15]:59895 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752456Ab1KXUxs (ORCPT ); Thu, 24 Nov 2011 15:53:48 -0500 Content-Disposition: inline In-Reply-To: <20111124192711.GM4387@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 SUSE Labs, CR