From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zheng Liu Subject: Re: Uninitialized extent races Date: Tue, 1 Jan 2013 00:31:46 +0800 Message-ID: <20121231163146.GA6795@gmail.com> References: <20121221012526.GD13474@quack.suse.cz> <20121221031151.GA5014@thunk.org> <20121221161929.GF17357@quack.suse.cz> <20121221180243.GB31731@thunk.org> <20121224111745.GA12051@gmail.com> <20121231083221.GA7564@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Theodore Ts'o , Dmitry Monakhov , linux-ext4@vger.kernel.org To: Jan Kara Return-path: Received: from mail-da0-f49.google.com ([209.85.210.49]:38009 "EHLO mail-da0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751209Ab2LaQSM (ORCPT ); Mon, 31 Dec 2012 11:18:12 -0500 Received: by mail-da0-f49.google.com with SMTP id v40so5784649dad.22 for ; Mon, 31 Dec 2012 08:18:12 -0800 (PST) Content-Disposition: inline In-Reply-To: <20121231083221.GA7564@quack.suse.cz> Sender: linux-ext4-owner@vger.kernel.org List-ID: On Mon, Dec 31, 2012 at 09:32:21AM +0100, Jan Kara wrote: > On Mon 24-12-12 19:17:45, Zheng Liu wrote: > > On Fri, Dec 21, 2012 at 01:02:43PM -0500, Theodore Ts'o wrote: > > > On Fri, Dec 21, 2012 at 05:19:29PM +0100, Jan Kara wrote: > > > > No, I'm speaking about merging currently uninitialized extents. I.e. > > > > suppose someone does the following on a filesystem with dioread_nolock so > > > > that writeback happens via unwritten extents: > > > > fd = open("file", O_RDWR); > > > > pwrite(fd, buf, 4096, 0); > > > > flusher thread starts writing > > > > we create uninitialized extent for > > > > range 0-4096 > > > > fallocate(fd, 0, 4096, 4096); > > > > - we merge extents and now have just 1 uninitialized extent for range > > > > 0-8192 > > > > ext4_convert_unwritten_extents() now > > > > has to split the extent to finish > > > > the IO. > > > > > > Ah, I see. Disabling the the merging that might take place as a > > > result of the fallocate. Yes, I agree that's a completely sane thing > > > to do. > > > > > > The alternate approach would be to add a flag in the extent status > > > tree indicating that an unwritten conversion is pending, but that > > > would add more complexity. > > > > Sorry for delay reply. Indeed we could add a flag in extent status tree > > to indicate an pending unwritten extent, and I believe that it can bring > > us some benefits. But I wonder whether this case often happens. Do we > > have some real workloads? > It doesn't happen often but it *can* happen. Thus you have to implement > a code which handles the case. I don't think bit in extent status tree is > really necessary. Just disabling merging of uninitialized extents is > simple. If we see there are some real workloads which have problems with > it, we can resort to a more complex solution using extent tree... Thanks for your explanation. I don't know whether or not you have generated a patch for this problem. I am willing to make it in a proper time. If you have begun to generate it, please let me know. :-) Happy New Year, - Zheng