From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:50142 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707AbeC2OMm (ORCPT ); Thu, 29 Mar 2018 10:12:42 -0400 Date: Thu, 29 Mar 2018 10:12:42 -0400 (EDT) From: Bob Peterson To: Andreas Gruenbacher Cc: cluster-devel@redhat.com, Christoph Hellwig , Dave Chinner , linux-fsdevel@vger.kernel.org Message-ID: <1702795937.14837153.1522332762084.JavaMail.zimbra@redhat.com> In-Reply-To: <20180328180106.31007-1-agruenba@redhat.com> References: <20180328180106.31007-1-agruenba@redhat.com> Subject: Re: [PATCH] gfs2: Zero out fallocated blocks in fallocate_chunk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: ----- Original Message ----- | Instead of zeroing out fallocated blocks in gfs2_iomap_alloc, zero them | out in fallocate_chunk, much higher up the call stack. This gets rid of | gfs2's abuse of the IOMAP_ZERO flag as well as the gfs2 specific zeronew | buffer flag. I can't think of a reason why zeroing out the blocks in | gfs2_iomap_alloc would have any benefits: there is no additional locking | at that level that would add protection to the newly allocated blocks. | | While at it, change fallocate over from gs2_block_map to gfs2_iomap_begin. | | Signed-off-by: Andreas Gruenbacher | --- Hi, Thanks. This is now pushed to the for-next branch of the linux-gfs2 tree: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=fffb64127adc3eea6a19ceefdc88d171f68b9d34 Regards, Bob Peterson Red Hat File Systems