From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753535AbYIVR0k (ORCPT ); Mon, 22 Sep 2008 13:26:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751591AbYIVR0b (ORCPT ); Mon, 22 Sep 2008 13:26:31 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]:58720 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbYIVR0b (ORCPT ); Mon, 22 Sep 2008 13:26:31 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references:x-google-sender-auth; b=u3zkWfGS7T//X9exw04fqYJ+dZPA6bGl8uxe66KUeQhglflYab8nhGj/NxKwaRJyI+ iUPNXHtn22Kxxce95JeOn0T1hOCYlPmt6ab6SBWzyYUVmnh1AsXej1q8Z7HuVLkmNrzJ Qe1NATAWYbMGph8B0TaehCJSx27vimPh2f4vA= Message-ID: <76bd70e30809221026g7bde774pbffa35881682ea4b@mail.gmail.com> Date: Mon, 22 Sep 2008 13:26:27 -0400 From: "Chuck Lever" Reply-To: chucklever@gmail.com To: "Aaron Straus" Subject: Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20 Cc: "Trond Myklebust" , "Hans-Peter Jansen" , linux-kernel@vger.kernel.org, "Neil Brown" , "Linux NFS Mailing List" In-Reply-To: <20080922170414.GC12483@merfinllc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080905191939.GG22796@merfinllc.com> <56258A29-95D5-4A8C-A097-014B8FEDFB8F@oracle.com> <20080911184951.GB19054@merfinllc.com> <200809221805.48463.hpj@urpla.net> <1222101322.7615.6.camel@localhost> <20080922170414.GC12483@merfinllc.com> X-Google-Sender-Auth: 457a413f817a30a1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 22, 2008 at 1:04 PM, Aaron Straus wrote: > Hi, > > On Sep 22 12:35 PM, Trond Myklebust wrote: >> Revert _what_ exactly? > > Yep. I narrowed the problem down to an offending hunk in a particular > patch. Removing that hunk did eliminate the problem. However, > reverting that hunk is likely wrong and the code has changed _a lot_ > since that commit. > >> My understanding was that this is a consequence of unordered writes >> causing the file to be extended while some other task is reading. > > Yes. I added some debugging statements to look at the writeout path. > > I think the following happens: > > - page 0 gets partially written to by app > - VM writes out partial dirty page 0 > - page 0 gets fully written by app > - page 1 gets partially written by app > - VM writes out dirty page 1 > > At this point there is a hole in the file. The tail end of page 0 is > still not written to server. > > - VM writes out dirty page 0 > ... > >> AFAICS, this sort of behaviour has _always_ been possible. I can't see >> how reverting anything will fix it. > > Here is the crux. It was possible previously but unlikely e.g. our app > never saw this behavior. The new writeout semantics causes visible > holes in files often. > > Anyway, I agree the new writeout semantics are allowed and possibly > saner than the previous writeout path. The problem is that it is > __annoying__ for this use case (log files). > > I'm not sure if there is an easy solution. We want the VM to writeout > the address space in order. Maybe we can start the scan for dirty > pages at the last page we wrote out i.e. page 0 in the example above? Why can't you use O_SYNC | O_APPEND ? -- Chuck Lever