Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx62.netapp.com ([216.240.31.182]:52463 "EHLO mx62.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753283AbbBKTMT (ORCPT ); Wed, 11 Feb 2015 14:12:19 -0500 Message-ID: <54DBA70E.9030903@Netapp.com> Date: Wed, 11 Feb 2015 14:01:34 -0500 From: Anna Schumaker MIME-Version: 1.0 To: Trond Myklebust , Tom Haynes CC: Marc Eshel , Anna Schumaker , "J. Bruce Fields" , Christoph Hellwig , Linux NFS Mailing List , Subject: Re: [PATCH v2 2/4] NFSD: Add READ_PLUS support for data segments References: <54D394EC.9030902@Netapp.com> <20150205162326.GA18977@infradead.org> <54D39DC2.9060808@Netapp.com> <20150205164832.GB4289@fieldses.org> <54DB7D72.5020001@Netapp.com> <20150211162244.GH25696@fieldses.org> <20150211181750.GB80012@kitty.kitty> In-Reply-To: Content-Type: text/plain; charset="utf-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On 02/11/2015 01:49 PM, Trond Myklebust wrote: > On Wed, Feb 11, 2015 at 1:17 PM, Tom Haynes > wrote: >> On Wed, Feb 11, 2015 at 12:47:26PM -0500, Trond Myklebust wrote: >>> On Wed, Feb 11, 2015 at 12:39 PM, Marc Eshel wrote: >>>> >>>> A good hint that we are dealing with a sparse file is the the number of >>>> blocks don't add up to the reported filesize >>> >>> Sure, but that still adds up to an unnecessary inefficiency on each >>> READ_PLUS call to that file. >>> >>> My point is that the best way for the client to process this >>> information (and for the server too) is to read the sparseness map in >>> once as a bulk operation on a very large chunk of the file, and then >>> to use that map as a guide for when it needs to call READ. >> >> I thought we agreed that the sparseness map made no sense because >> the information was immeadiately stale? > > Right now, we're caching the zero reads, aren't we? What makes caching > hole information so special? > >> Anyway, the client could build that map if it wanted to using SEEK. I'm >> not arguing that it would be efficient, but that it could be done >> with a cycle of looking for holes. > > Sure, however that's not necessarily useful as an optimiser either. The vfs on Linux doesn't keep a sparse map either, so the server would be stuck doing seeks to build this up anyway. I've already seen that this can be somewhat unreliable while working on READ_PLUS. > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >