Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934673Ab0KQJap (ORCPT ); Wed, 17 Nov 2010 04:30:45 -0500 Received: from idcmail-mo2no.shaw.ca ([64.59.134.9]:37723 "EHLO idcmail-mo2no.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934588Ab0KQJan convert rfc822-to-8bit (ORCPT ); Wed, 17 Nov 2010 04:30:43 -0500 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=EPI+Anp5axUU12/DJ58YCKzU/28JrKwJBM9MxN4j1qY= c=1 sm=1 a=-7GN7jtwYLcA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=c23vf5CSMVc0QQz9B4a6RA==:17 a=SZPcMJaOT5KGTx3Jp3cA:9 a=tFfODJ8DFMr_qifDV7cA:7 a=hAFdFT0FYBrWpLKb9ULSG0gI0q0A:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Andreas Dilger In-Reply-To: <20101117023456.GD5618@dhcp231-156.rdu.redhat.com> Date: Wed, 17 Nov 2010 03:30:40 -0600 Cc: Dave Chinner , 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 Content-Transfer-Encoding: 8BIT Message-Id: <23A45B17-C23C-45DA-8C51-1CF315C851E2@dilger.ca> 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> <20101117023456.GD5618@dhcp231-156.rdu.redhat.com> To: Josef Bacik X-Mailer: Apple Mail (2.1081) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1405 Lines: 20 On 2010-11-16, at 20:34, Josef Bacik wrote: > 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" Even if this is the case, and we decide today that PUNCH_HOLE without KEEP_SIZE is not desirable to implement, it would be better to just return -EOPNOTSUPP if both flags are not set than assume one or the other is what the user wanted. That allows the ability to implement this in the future without breaking every application, while if it is assumed that KEEP_SIZE is always implicit there will never be a way to add that functionality without something awful like a separate CHANGE_SIZE flag for PUNCH_HOLE. One option is to define FALLOC_FL_PUNCH_HOLE as 0x3 (so that KEEP_SIZE is always passed) and in the future we can define some new flag name like TRUNCATE_HOLE (or whatever) that is 0x2 only. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/