From owner-freebsd-fs@FreeBSD.ORG Thu Nov 28 00:19:55 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A72F8988 for ; Thu, 28 Nov 2013 00:19:55 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 69F83852 for ; Thu, 28 Nov 2013 00:19:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAE2LllKDaFve/2dsb2JhbABZhBKCerVJgTd0giUBAQUjVhsRAwECAQICDRkCIy4IBhOHbwMPrwiIXQ2IAheBKYtIgV00B4JrgUgDiUKMZ45FhTmDRx6Bbg X-IronPort-AV: E=Sophos;i="4.93,786,1378872000"; d="scan'208";a="74149290" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 27 Nov 2013 19:19:47 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C1B49B3F4E; Wed, 27 Nov 2013 19:19:47 -0500 (EST) Date: Wed, 27 Nov 2013 19:19:47 -0500 (EST) From: Rick Macklem To: Kirk McKusick Message-ID: <1476192898.22291791.1385597987782.JavaMail.root@uoguelph.ca> In-Reply-To: <201311272320.rARNKEKQ045789@chez.mckusick.com> Subject: Re: RFC: NFS client patch to reduce sychronous writes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 00:19:55 -0000 Kirk wrote: > > Date: Wed, 27 Nov 2013 17:50:48 -0500 (EST) > > From: Rick Macklem > > To: Konstantin Belousov > > Subject: Re: RFC: NFS client patch to reduce sychronous writes > > > > Kostik wrote: > >> Sorry, I do not understand the question. mmap(2) itself does not > >> change > >> file size. But if mmaped area includes the last page, I still > >> think > >> that the situation I described before is possible. > > > > Yes, I'll need to look at this. If it is a problem, all I can think > > of > > is bzeroing all new pages when they're allocated to the buffer > > cache. > > > > Thanks for looking at it, rick > > ps: Btw, jhb@'s patch didn't have the bzeroing in it. > > The ``fix'' of bzero'ing every buffer cache page was made to UFS/FFS > for this problem and it killed write performance of the filesystem > by nearly half. We corrected this by only doing the bzero when the > file is mmap'ed which helped things considerably (since most files > being written are not also bmap'ed). > > Kirk > Ok, thanks. I've been trying to reproduce the problem over NFS and haven't been able to break my patch. I was using the attached trivial test program and would simply make a copy of the source file (529 bytes) to test on. I got the same results both locally and over NFS: - built without -DWRITEIT, the setting of a value after EOF would be lost, because nothing grew the file from 529 bytes to over 4080bytes. - built with -DWRITEIT, both the 'A' and 'B' are in the result, since my patch bzeros the grown segment in the write(2) syscall. - If I move the write (code in #ifdef WRITEIT) to after the "*cp" of the mapped page, the 'A' assigned to "*cp" gets lost for both UFS and NFS. Is this correct behaviour? If it is correct behaviour, I can't see how the patch is broken, but if you think it might still be, I'll look at doing what Kirk suggests, which is bzeroing all new buffer cache pages when the file is mmap()d. Thanks for the help, rick