From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:33228 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751866AbeCONUn (ORCPT ); Thu, 15 Mar 2018 09:20:43 -0400 Date: Thu, 15 Mar 2018 09:20:42 -0400 (EDT) From: Bob Peterson To: Christoph Hellwig Cc: Andreas Gruenbacher , Dave Chinner , linux-fsdevel@vger.kernel.org Message-ID: <1505831988.11289790.1521120042544.JavaMail.zimbra@redhat.com> In-Reply-To: <20180313082232.GA666@lst.de> References: <20180313082232.GA666@lst.de> Subject: Re: gfs2 IOMAP_ZERO confusion 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 ----- | Hi Bob, | | In "GFS2: Implement iomap for block_map" you seem to have misunderstood | the intention of the IOMAP_ZERO flag. It it set if iomap_begin is | called for a zeroing operation, so that we don't allocate new blocks | for holes or unwritten extents. It is not supposed to actually zero | the blocks. Can you use some other way to communicate you internal | zeroing request? | Hi Christoph, I guess I misappropriated the flag because it seemed like a convenient way to handle the buffer_zeronew() flag for our block_map function. The problem is: since GFS2 is not extent-based, we have no good way to mark groups of blocks as needing to be zeroed in the future, for purposes like fallocate. I wish there was. There's definitely not enough bits in our (2-bits-per-block) bitmap for that, although that would be nice. So we can either add in a new iomap flag and do it when it's convenient, or else handle the zeroing separately from functions that call iomap, like in gfs2_block_map, fallocate, and so forth. Or perhaps something that runs in the background like from a workqueue, etc. What are your thoughts? Regards, Bob Peterson Red Hat File Systems