Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3541170pxv; Mon, 26 Jul 2021 06:29:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzb8MllUQYkiGIPSx7lZk5/g9vW1yMQQdBNC/CplsWE4DhkTPmxArDvcMKlfe+0WpPv9Djm X-Received: by 2002:a92:cd4d:: with SMTP id v13mr13074183ilq.107.1627306156664; Mon, 26 Jul 2021 06:29:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627306156; cv=none; d=google.com; s=arc-20160816; b=eH7Xj/wwRJ8QxfuEn3aWdp6012iZmxx5sqvhNTY9uDBRncmX4oqZ+rTyqAVrtH1tfn fb4qM7I3hoq5W+S1Pwpl8EpLs/VYuRTWeceNePXDhztC+rVDu+TopNVg2OkgfsMhLP5v XIDYqENLjNTlFECrj2lqJUQWF5I4w0rS0W1fbzmHndCyeRlNlX9Zav/mkTSqEmnurp2d dvMl5Y+f9MiLMGK0abcr68dicPpeUJjCI7muNZgwCdGBk6lT4o/PNhvujAgNCkXW2kRZ Be0EDWGfe7gnqJC/QruIA5zHC52cgXcALeVryFDFJCJBqE/VhEBfQebWL56dQAeI42xA LMWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Rj/aV1ROyuSRLxRByrEyF64/rrI/rDV5SlMQpNSYvUE=; b=k8iEwT2qmxxkD7luNpkH8kgkaOb715MRmlZVzkJQoucLqZjvUQ+C9lBcGZ1maZAkxJ QoAlCDw6UlMhRyOpgWY6hUyLLjgFPKTb/PGxWCmzu5nRtOqveeyfjD2V1Iqe34z5TMzc MfyKINqtGa88IA/i6WUnuKdxHZGok0C0h9JQPw6cfMWqelpRr6Wd83d7EeA4rZ0W4Eml LdAyEqsX+utyVO4y3E5YSwkJdHa9ZFx6oXwmzBKnb5xo8gUBPKBVGT/IRa1XmTWQT4i2 WFIlWzXPwQoZ5ml6LUBzruLOeJXFjfpSFNw2fLvsQFPZdqnIGg/ffYfWNE4zKKvrARXL Xh7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d17si24056502ilf.150.2021.07.26.06.29.04; Mon, 26 Jul 2021 06:29:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233452AbhGZMrX (ORCPT + 99 others); Mon, 26 Jul 2021 08:47:23 -0400 Received: from verein.lst.de ([213.95.11.211]:45189 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232572AbhGZMrX (ORCPT ); Mon, 26 Jul 2021 08:47:23 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 5A9F867373; Mon, 26 Jul 2021 15:27:49 +0200 (CEST) Date: Mon, 26 Jul 2021 15:27:49 +0200 From: Christoph Hellwig To: Andreas =?iso-8859-1?Q?Gr=FCnbacher?= Cc: Christoph Hellwig , Andreas Gruenbacher , Gao Xiang , "Darrick J . Wong" , Matthew Wilcox , Huang Jianan , linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH v7] iomap: make inline data support more flexible Message-ID: <20210726132749.GA6535@lst.de> References: <20210723174131.180813-1-hsiangkao@linux.alibaba.com> <20210725221639.426565-1-agruenba@redhat.com> <20210726110611.459173-1-agruenba@redhat.com> <20210726121702.GA528@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 26, 2021 at 02:27:12PM +0200, Andreas Gr?nbacher wrote: > > That is how can size be different from iomap->length? > > Quoting from my previous reply, > > "In the iomap_readpage case (iomap_begin with flags == 0), > iomap->length will be the amount of data up to the end of the inode. > In the iomap_file_buffered_write case (iomap_begin with flags == > IOMAP_WRITE), iomap->length will be the size of iomap->inline_data. > (For extending writes, we need to write beyond the current end of > inode.) So iomap->length isn't all that useful for > iomap_read_inline_data." I think we should fix that now that we have the srcmap concept. That is or IOMAP_WRITE|IOMAP_ZERO return the inline map as the soure map, and return the actual block map we plan to write into as the main iomap. > > > Shouldn't the offset_in_page also go into iomap_inline_data_size_valid, > > which should probably be called iomap_inline_data_valid then? > > Hmm, not sure what you mean: iomap_inline_data_size_valid does take > offset_in_page(iomap->inline_data) into account. Indeed, orry for the braino. > I thought people were okay with 80 character long lines? No.