Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx11.netapp.com ([216.240.18.76]:44045 "EHLO mx11.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945Ab3KDS5F (ORCPT ); Mon, 4 Nov 2013 13:57:05 -0500 Message-ID: <5277EDFE.50500@netapp.com> Date: Mon, 4 Nov 2013 13:57:02 -0500 From: Anna Schumaker MIME-Version: 1.0 To: Christoph Hellwig CC: , Subject: Re: [PATCH 3/4] NFSD: Add WRITE_PLUS support for hole punches References: <1382972247-1108-1-git-send-email-bjschuma@netapp.com> <1382972247-1108-4-git-send-email-bjschuma@netapp.com> <20131102135238.GB18961@infradead.org> <5277CE23.6010207@netapp.com> <20131104170345.GA31499@infradead.org> <5277D80F.8050106@netapp.com> <20131104185309.GA14378@infradead.org> In-Reply-To: <20131104185309.GA14378@infradead.org> Content-Type: text/plain; charset="ISO-8859-1" Sender: linux-nfs-owner@vger.kernel.org List-ID: On 11/04/2013 01:53 PM, Christoph Hellwig wrote: > On Mon, Nov 04, 2013 at 12:23:27PM -0500, Anna Schumaker wrote: >>> state" that will return zeroes when read, even if those zeroes didn't >>> make it to disk. >> >> And that's all done through metadata? Doing the commit_metadata() call makes a bit more sense now. > > Yes. The only filesystem in tree that actually seems to write zeroes > is gfs2, but even then it doesn't do so through the usual mechanisms. > >>> Also what does the data arm buy us over good old WRITE? >>> >> >> I've been working off of draft #21, the most recent commit is 2b3ab1740b1ea843faa59566fb4213a42d8c724a from Aug 19. The eventual goal is to phase out WRITE and replace it with WRITE_PLUS, but that won't happen until at least 4.3. I don't know why it's being done this way instead of just adding an FALLOCATE operation. > > Where can I find draft 21? The newest document in the git repo I was > pointed to earlier is draft-ietf-nfsv4-minorversion2-13.txt, and the > newest I could find on tools.ietf.org is draft 20. You may need to run `make` in the NFSv4.2 directory. > > I still don't understand why anyone would phase out WRITE in favour of > something that doesn't actually add any value for the write case. > > I'll try to take it up directly with the working group, but my post to > the list yesterday in your SEEK thread didn't seem to have made it > trough. I also tried to research how they came up with this idiotic > design, but the mailing list archives tell very little. Could it be > that most of these decisions are actually made in a smokey backroom and > not on the list? >