Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4872081ybv; Wed, 26 Feb 2020 04:32:23 -0800 (PST) X-Google-Smtp-Source: APXvYqyLlkyS8iSKVc9dnX2px0QkIbuJq5pmKWZhgSLeHqKkX9EhTUUf2p/DtNiBs5/rQxQK51cr X-Received: by 2002:aca:4ad8:: with SMTP id x207mr2693333oia.55.1582720343593; Wed, 26 Feb 2020 04:32:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582720343; cv=none; d=google.com; s=arc-20160816; b=IOtSlMbkrEtb0qdIXwvlnsJDsrqyz35fJ3Iw8AObK10CpkyeRsXDFToBnzLAp6QTnD 7IqmHw2kP9wAhOKawLmiXveESVsua4E1uwGyMadnXztteaSliU861xFi3RTJ61Je0iLO Vc8z18Tp+NBbKC50wRr9RRKgmCX+ctFFRGE8QtKNE61QhrNTHFYGHlEljpfVUt5i4/DH 7KZg5o2227heE2S6Gq8/RQqRH5bzPNIHe/z8X/GVuUoI8WL3tURBb0lYozWzc8o+/9J5 nZuGlrvcoH676eUxaH7jZLS8tuQp9s2QRPJ+sZJLB1HNU1OpPcvSmF0burkU099wNntQ F3bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pwnJBk21XHrwgdFJT+c44HP8utDpvYb2ftMnexJfTCQ=; b=T2cPGKkewkp9LoLxtByYHrNrNHal1Vac7dmTy+TnfL4r0en9F6QrzL959lYZxK1doB NDPE9ByC5t2FMUI4YNDL3Xk2ryULsCoSDvqnnEkD1mm0OjrCKAfJD6tldhq9vH5gPH7+ wkq8uDki5FhaZ1e/EW1n+C0MFkuMi640SVEOTGra+Qze3rKluBvef57Mr33rUttTuFrn BEJF2LDPpGZWn39pEt9E+0qA+gJOi83hyFILdQKL33FhC0mbSqzCoAa478Z5tqXbk6FL qgvKAsrLOBQTBRHNyBMrk928Zm7xP5fMyhIMpLeIKp06JPLZ0j/AXut/l2J6Y/RW4wxC fYVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w187si1089188oif.94.2020.02.26.04.32.05; Wed, 26 Feb 2020 04:32:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727118AbgBZM07 (ORCPT + 99 others); Wed, 26 Feb 2020 07:26:59 -0500 Received: from mx2.suse.de ([195.135.220.15]:41826 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726579AbgBZM07 (ORCPT ); Wed, 26 Feb 2020 07:26:59 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D7234AC53; Wed, 26 Feb 2020 12:26:56 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 926401E0EA2; Wed, 26 Feb 2020 13:26:55 +0100 (CET) Date: Wed, 26 Feb 2020 13:26:55 +0100 From: Jan Kara To: Ritesh Harjani Cc: jack@suse.cz, tytso@mit.edu, linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca, linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com, hch@infradead.org, cmaiolino@redhat.com Subject: Re: [PATCHv3 1/6] ext4: Add IOMAP_F_MERGED for non-extent based mapping Message-ID: <20200226122655.GM10728@quack2.suse.cz> References: <25695b1a4bc3b5c3a2f513ecb612195aa7154975.1582702693.git.riteshh@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25695b1a4bc3b5c3a2f513ecb612195aa7154975.1582702693.git.riteshh@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed 26-02-20 15:27:03, Ritesh Harjani wrote: > IOMAP_F_MERGED needs to be set in case of non-extent based mapping. > This is needed in later patches for conversion of ext4_fiemap to use iomap. > > Signed-off-by: Ritesh Harjani > --- > fs/ext4/inode.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index d035acab5b2a..3b4230cf0bc2 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -3335,6 +3335,10 @@ static void ext4_set_iomap(struct inode *inode, struct iomap *iomap, > iomap->offset = (u64) map->m_lblk << blkbits; > iomap->length = (u64) map->m_len << blkbits; > > + if ((map->m_flags & (EXT4_MAP_UNWRITTEN | EXT4_MAP_MAPPED)) && > + !ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) ^^ we indent the second line of condition either like: if ((map->m_flags & (EXT4_MAP_UNWRITTEN | EXT4_MAP_MAPPED)) && !ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) or like: if ((map->m_flags & (EXT4_MAP_UNWRITTEN | EXT4_MAP_MAPPED)) && !ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) But on at the same level as following code block because that's highly confusing at times... Also EXT4_MAP_UNWRITTEN is never set for indirect block mapped files (that on disk format does not support unwritten extents). Honza > + iomap->flags |= IOMAP_F_MERGED; > + > /* > * Flags passed to ext4_map_blocks() for direct I/O writes can result > * in m_flags having both EXT4_MAP_MAPPED and EXT4_MAP_UNWRITTEN bits > -- > 2.21.0 > -- Jan Kara SUSE Labs, CR