From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josef Bacik Subject: Re: [PATCH 4/6] Ext4: fail if we try to use hole punch Date: Wed, 17 Nov 2010 01:31:26 -0500 Message-ID: <20101117063125.GE5618@dhcp231-156.rdu.redhat.com> References: <1289840723-3056-1-git-send-email-josef@redhat.com> <1289840723-3056-5-git-send-email-josef@redhat.com> <4CE2783F.1020004@redhat.com> <20101116125016.GA31957@dhcp231-156.rdu.redhat.com> <4CE28211.6060204@redhat.com> <20101117030640.GD3290@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: "Ted Ts'o" , Avi Kivity , Josef Bacik , david@fromorbit.com, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vge Return-path: In-Reply-To: <20101117030640.GD3290@thunk.org> List-ID: On Tue, Nov 16, 2010 at 10:06:40PM -0500, Ted Ts'o wrote: > > >There is no simple way to test if a filesystem supports hole punching or not so > > >the check has to be done per fs. Thanks, > > > > Could put a flag word in superblock_operations. Filesystems which > > support punching (or other features) can enable it there. > > No, it couldn't be in super_operations. It may vary on a per-inode > basis for some file systems, such as ext4 (depending on whether the > inode is extent-mapped or indirect-block mapped). > > So at least for ext4 we'd need to call into fallocate() function > anyway, once we add support. I suppose if other file systems really > want it, we could add a flag to the super block ops structure, so they > don't have do the "do we support the punch" operation. I can go > either way on that; although if we think the majority of file systems > are going support punch in the long-term, then it might not be worth > it to add such a flag. > Yeah thats alot of extra code just for one part of fallocate. Calling into ->fallocate is perfectly reasonable, especially since ext4 works the way it does, I'm going to leave things as they are. Thanks, Josef From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934385Ab0KQGcZ (ORCPT ); Wed, 17 Nov 2010 01:32:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25761 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933323Ab0KQGcX (ORCPT ); Wed, 17 Nov 2010 01:32:23 -0500 Date: Wed, 17 Nov 2010 01:31:26 -0500 From: Josef Bacik To: "Ted Ts'o" , Avi Kivity , Josef Bacik , david@fromorbit.com, 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 Subject: Re: [PATCH 4/6] Ext4: fail if we try to use hole punch Message-ID: <20101117063125.GE5618@dhcp231-156.rdu.redhat.com> References: <1289840723-3056-1-git-send-email-josef@redhat.com> <1289840723-3056-5-git-send-email-josef@redhat.com> <4CE2783F.1020004@redhat.com> <20101116125016.GA31957@dhcp231-156.rdu.redhat.com> <4CE28211.6060204@redhat.com> <20101117030640.GD3290@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101117030640.GD3290@thunk.org> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 16, 2010 at 10:06:40PM -0500, Ted Ts'o wrote: > > >There is no simple way to test if a filesystem supports hole punching or not so > > >the check has to be done per fs. Thanks, > > > > Could put a flag word in superblock_operations. Filesystems which > > support punching (or other features) can enable it there. > > No, it couldn't be in super_operations. It may vary on a per-inode > basis for some file systems, such as ext4 (depending on whether the > inode is extent-mapped or indirect-block mapped). > > So at least for ext4 we'd need to call into fallocate() function > anyway, once we add support. I suppose if other file systems really > want it, we could add a flag to the super block ops structure, so they > don't have do the "do we support the punch" operation. I can go > either way on that; although if we think the majority of file systems > are going support punch in the long-term, then it might not be worth > it to add such a flag. > Yeah thats alot of extra code just for one part of fallocate. Calling into ->fallocate is perfectly reasonable, especially since ext4 works the way it does, I'm going to leave things as they are. Thanks, Josef From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oAH6UmHP196229 for ; Wed, 17 Nov 2010 00:30:49 -0600 Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 40C2A13C7AA0 for ; Tue, 16 Nov 2010 22:32:21 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id dEP3C2bSdefWVqLv for ; Tue, 16 Nov 2010 22:32:21 -0800 (PST) Date: Wed, 17 Nov 2010 01:31:26 -0500 From: Josef Bacik Subject: Re: [PATCH 4/6] Ext4: fail if we try to use hole punch Message-ID: <20101117063125.GE5618@dhcp231-156.rdu.redhat.com> References: <1289840723-3056-1-git-send-email-josef@redhat.com> <1289840723-3056-5-git-send-email-josef@redhat.com> <4CE2783F.1020004@redhat.com> <20101116125016.GA31957@dhcp231-156.rdu.redhat.com> <4CE28211.6060204@redhat.com> <20101117030640.GD3290@thunk.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20101117030640.GD3290@thunk.org> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Ted Ts'o , Avi Kivity , Josef Bacik , david@fromorbit.com, 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 On Tue, Nov 16, 2010 at 10:06:40PM -0500, Ted Ts'o wrote: > > >There is no simple way to test if a filesystem supports hole punching or not so > > >the check has to be done per fs. Thanks, > > > > Could put a flag word in superblock_operations. Filesystems which > > support punching (or other features) can enable it there. > > No, it couldn't be in super_operations. It may vary on a per-inode > basis for some file systems, such as ext4 (depending on whether the > inode is extent-mapped or indirect-block mapped). > > So at least for ext4 we'd need to call into fallocate() function > anyway, once we add support. I suppose if other file systems really > want it, we could add a flag to the super block ops structure, so they > don't have do the "do we support the punch" operation. I can go > either way on that; although if we think the majority of file systems > are going support punch in the long-term, then it might not be worth > it to add such a flag. > Yeah thats alot of extra code just for one part of fallocate. Calling into ->fallocate is perfectly reasonable, especially since ext4 works the way it does, I'm going to leave things as they are. Thanks, Josef _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josef Bacik Date: Wed, 17 Nov 2010 06:32:21 -0000 Subject: [Ocfs2-devel] [PATCH 4/6] Ext4: fail if we try to use hole punch In-Reply-To: <20101117030640.GD3290@thunk.org> References: <1289840723-3056-1-git-send-email-josef@redhat.com> <1289840723-3056-5-git-send-email-josef@redhat.com> <4CE2783F.1020004@redhat.com> <20101116125016.GA31957@dhcp231-156.rdu.redhat.com> <4CE28211.6060204@redhat.com> <20101117030640.GD3290@thunk.org> Message-ID: <20101117063125.GE5618@dhcp231-156.rdu.redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ted Ts'o , Avi Kivity , Josef Bacik , david@fromorbit.com, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vge On Tue, Nov 16, 2010 at 10:06:40PM -0500, Ted Ts'o wrote: > > >There is no simple way to test if a filesystem supports hole punching or not so > > >the check has to be done per fs. Thanks, > > > > Could put a flag word in superblock_operations. Filesystems which > > support punching (or other features) can enable it there. > > No, it couldn't be in super_operations. It may vary on a per-inode > basis for some file systems, such as ext4 (depending on whether the > inode is extent-mapped or indirect-block mapped). > > So at least for ext4 we'd need to call into fallocate() function > anyway, once we add support. I suppose if other file systems really > want it, we could add a flag to the super block ops structure, so they > don't have do the "do we support the punch" operation. I can go > either way on that; although if we think the majority of file systems > are going support punch in the long-term, then it might not be worth > it to add such a flag. > Yeah thats alot of extra code just for one part of fallocate. Calling into ->fallocate is perfectly reasonable, especially since ext4 works the way it does, I'm going to leave things as they are. Thanks, Josef