X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oAH2Y7Ig159693 for ; Tue, 16 Nov 2010 20:34:07 -0600 X-ASG-Debug-ID: 1289961340-0c3300bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B51BB187A7A for ; Tue, 16 Nov 2010 18:35:40 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id V3IvMLf4ixYWz0JZ for ; Tue, 16 Nov 2010 18:35:40 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oAH2ZZ9x021963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Nov 2010 21:35:35 -0500 Received: from dhcp231-156.rdu.redhat.com (dhcp231-156.rdu.redhat.com [10.11.231.156]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oAH2ZU2n021559; Tue, 16 Nov 2010 21:35:30 -0500 Date: Tue, 16 Nov 2010 21:34:56 -0500 From: Josef Bacik To: Josef Bacik Cc: Dave Chinner , Andreas Dilger , Jan Kara , linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, cmm@us.ibm.com, cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com X-ASG-Orig-Subj: Re: [PATCH 1/6] fs: add hole punching to fallocate Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate Message-ID: <20101117023456.GD5618@dhcp231-156.rdu.redhat.com> References: <1289840723-3056-1-git-send-email-josef@redhat.com> <1289840723-3056-2-git-send-email-josef@redhat.com> <20101116111611.GA4757@quack.suse.cz> <20101116114346.GB4757@quack.suse.cz> <20101116125249.GB31957@dhcp231-156.rdu.redhat.com> <20101116131451.GH4757@quack.suse.cz> <18ACAA85-8847-4B12-9839-F99FB6C7B3E4@dilger.ca> <20101117021150.GL22876@dastard> <20101117022814.GB5618@dhcp231-156.rdu.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101117022814.GB5618@dhcp231-156.rdu.redhat.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1289961340 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Nov 16, 2010 at 09:28:14PM -0500, Josef Bacik wrote: > On Wed, Nov 17, 2010 at 01:11:50PM +1100, Dave Chinner wrote: > > On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote: > > > On 2010-11-16, at 07:14, Jan Kara wrote: > > > >> Yeah I went back and forth on this. KEEP_SIZE won't change the > > > >> behavior of PUNCH_HOLE since PUNCH_HOLE implicitly means keep > > > >> the size. I figured since its "mode" and not "flags" it would > > > >> be ok to make either way accepted, but if you prefer PUNCH_HOLE > > > >> means you have to have KEEP_SIZE set then I'm cool with that, > > > >> just let me know one way or the other. > > > > > > > > So we call it "mode" but speak about "flags"? Seems a bit > > > > inconsistent. I'd maybe lean a bit at the "flags" side and just > > > > make sure that only one of FALLOC_FL_KEEP_SIZE, > > > > FALLOC_FL_PUNCH_HOLE is set (interpreting FALLOC_FL_KEEP_SIZE as > > > > allocate blocks beyond i_size). But I'm not sure what others > > > > think. > > > > > > IMHO, it makes more sense for consistency and "get what users > > > expect" that these be treated as flags. Some users will want > > > KEEP_SIZE, but in other cases it may make sense that a hole punch > > > at the end of a file should shrink the file (i.e. the opposite of > > > an append). > > > > What's wrong with ftruncate() for this? > > > > There's plenty of open questions about the interface if we allow > > hole punching to change the file size. e.g. where do we set the EOF > > (offset or offset+len)? What do we do with the rest of the blocks > > that are now beyond EOF? We weren't asked to punch them out, so do > > we leave them behind? What if we are leaving written blocks beyond > > EOF - does any filesystem other than XFS support that (i.e. are we > > introducing different behaviour on different filesystems)? And what > > happens if the offset is beyond EOF? Do we extend the file, and if > > so why wouldn't you just use ftruncate() instead? > > > > IMO, allowing hole punching to change the file size makes it much > > more complicated and hence less likely to simply do what the user > > expects. It also is harder to implement and testing becomes much > > more intricate. From that perspective, it does not seem desirable to > > me... > > > > FWIW I agree with Dave, the only question at this point is do we force users to > specify KEEP_SIZE with PUNCH_HOLE? On one hand it makes the interface a bit > more consistent, on the other hand it makes the documentation a little weird > > "We have mode here, but if you want to use PUNCH_HOLE you also have to specify > KEEP_SIZE, so really it's like a flags field it's just named poorly" > > I have no strong opinions the other way so if nobody else does then I'll just do > it Jan's way. Thanks, > Sorry child induced sleep deprevation bleeding in there, that should read "I have no strong opinions one way or the other." Sheesh, Josef