Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx142.netapp.com ([216.240.21.19]:44029 "EHLO mx142.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752160AbbA2BNs (ORCPT ); Wed, 28 Jan 2015 20:13:48 -0500 Message-ID: <54C95860.3060109@Netapp.com> Date: Wed, 28 Jan 2015 16:45:04 -0500 From: Anna Schumaker MIME-Version: 1.0 To: Christoph Hellwig CC: , Subject: Re: [PATCH v2 0/4] NFSD: Add READ_PLUS support References: <1422477777-27933-1-git-send-email-Anna.Schumaker@Netapp.com> <20150128213832.GA24389@infradead.org> In-Reply-To: <20150128213832.GA24389@infradead.org> Content-Type: text/plain; charset="utf-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On 01/28/2015 04:38 PM, Christoph Hellwig wrote: > On Wed, Jan 28, 2015 at 03:42:53PM -0500, Anna.Schumaker@netapp.com wrote: >> From: Anna Schumaker >> >> These patches add server support for the NFS v4.2 operation READ_PLUS. >> >> I noticed a race condition in the 3rd patch when I start needing vfs_llseek() >> to determine if I should encode the next segment as either data or a hole. It >> is possible that the file could change on us between each of the seek calls, >> so we don't know if we are actually at a hole or data segment. I don't want to >> add new locks to the NFS server for this case, so instead I've decided to >> encode any "quantum data" segments as if they were actually data. >> >> I tested these patches using xfstests, specificially generic/075, generic/091, >> generic/112, generic/127, generic/210, and generic/263. Additionally, three >> new tests are run once READ_PLUS support has been added: generic/213, >> generic/214, and generic/228. > > Why do theses test start working when you use READ_PLUS? They should > only depend on ALLOCATE support, and maybe SEEK if we're trying to > figure out information about mappings somehow. I'm not sure. I'll rerun the tests to make sure I wasn't just confused when I typed that! Anna >