From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DB65C07E9B for ; Wed, 21 Jul 2021 07:30:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3FBF160FEA for ; Wed, 21 Jul 2021 07:30:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235016AbhGUGtL (ORCPT ); Wed, 21 Jul 2021 02:49:11 -0400 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:59771 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234659AbhGUGsY (ORCPT ); Wed, 21 Jul 2021 02:48:24 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0UgVICqi_1626852531; Received: from B-P7TQMD6M-0146.local(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0UgVICqi_1626852531) by smtp.aliyun-inc.com(127.0.0.1); Wed, 21 Jul 2021 15:28:52 +0800 Date: Wed, 21 Jul 2021 15:28:51 +0800 From: Gao Xiang To: Andreas =?utf-8?Q?Gr=C3=BCnbacher?= Cc: "Darrick J. Wong" , Matthew Wilcox , linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List , LKML , Christoph Hellwig Subject: Re: [PATCH v4] iomap: support tail packing inline read Message-ID: Mail-Followup-To: Andreas =?utf-8?Q?Gr=C3=BCnbacher?= , "Darrick J. Wong" , Matthew Wilcox , linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List , LKML , Christoph Hellwig References: <20210720133554.44058-1-hsiangkao@linux.alibaba.com> <20210720204224.GK23236@magnolia> <20210721001720.GS22357@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 21, 2021 at 08:43:00AM +0200, Andreas Grünbacher wrote: > Am Mi., 21. Juli 2021 um 04:54 Uhr schrieb Gao Xiang > : > > Hi Andreas, > > > > On Wed, Jul 21, 2021 at 04:26:47AM +0200, Andreas Grünbacher wrote: > > > Am Mi., 21. Juli 2021 um 02:33 Uhr schrieb Gao Xiang > > > : > > > > > And since you can only kmap one page at a time, an inline read grabs the > > > > > first part of the data in "page one" and then we have to call > > > > > iomap_begin a second time get a new address so that we can read the rest > > > > > from "page two"? > > > > > > > > Nope, currently EROFS inline data won't cross page like this. > > > > > > > > But in principle, yes, I don't want to limit it to the current > > > > EROFS or gfs2 usage. I think we could make this iomap function > > > > more generally (I mean, I'd like to make the INLINE extent > > > > functionity as general as possible, > > > > > > Nono. Can we please limit this patch what we actually need right now, > > > and worry about extending it later? > > > > Can you elaborate what it will benefit us if we only support one tail > > block for iomap_read_inline_data()? (I mean it has similar LOC changes, > > similar implementation / complexity.) The only concern I think is if > > it causes gfs2 regression, so that is what I'd like to confirm. > > iomap_read_inline_data supports one inline page now (i.e., from the > beginning of the file). It seems that you don't need more than one > tail page in EROFS, right? > > You were speculating about inline data in the middle of a file. That > sounds like a really, really bad idea to me, and I don't think we > should waste any time on it. Huh? why do you think it's a bad idea? I could give real example to you. At least, it can be used for some encoded data or repeated pattern (such as AABBAABBAABB...) in a packed way (marked in extent metadata). Is that enough? Again, I don't see what the benefits if limiting it to one tail block, it (maybe) just modifies: + /* handle tail-packing blocks cross the current page into the next */ + size = min_t(unsigned int, iomap->length + pos - iomap->offset, + PAGE_SIZE - poff); to + size = min_t(unsigned int, i_blocksize(inode), + PAGE_SIZE - poff); And which has the similar complexity, so why not using iomap->length here instead? Thanks, Gao Xiang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2863C07E9B for ; Wed, 21 Jul 2021 07:29:25 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2202A6008E for ; Wed, 21 Jul 2021 07:29:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2202A6008E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4GV6fC5Sq3z30BH for ; Wed, 21 Jul 2021 17:29:23 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.alibaba.com (client-ip=115.124.30.132; helo=out30-132.freemail.mail.aliyun.com; envelope-from=hsiangkao@linux.alibaba.com; receiver=) Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4GV6f815FBz2xfK for ; Wed, 21 Jul 2021 17:29:17 +1000 (AEST) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04400; MF=hsiangkao@linux.alibaba.com; NM=1; PH=DS; RN=7; SR=0; TI=SMTPD_---0UgVICqi_1626852531; Received: from B-P7TQMD6M-0146.local(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0UgVICqi_1626852531) by smtp.aliyun-inc.com(127.0.0.1); Wed, 21 Jul 2021 15:28:52 +0800 Date: Wed, 21 Jul 2021 15:28:51 +0800 From: Gao Xiang To: Andreas =?utf-8?Q?Gr=C3=BCnbacher?= Subject: Re: [PATCH v4] iomap: support tail packing inline read Message-ID: Mail-Followup-To: Andreas =?utf-8?Q?Gr=C3=BCnbacher?= , "Darrick J. Wong" , Matthew Wilcox , linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List , LKML , Christoph Hellwig References: <20210720133554.44058-1-hsiangkao@linux.alibaba.com> <20210720204224.GK23236@magnolia> <20210721001720.GS22357@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Darrick J. Wong" , LKML , Matthew Wilcox , Linux FS-devel Mailing List , linux-erofs@lists.ozlabs.org, Christoph Hellwig Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On Wed, Jul 21, 2021 at 08:43:00AM +0200, Andreas Grünbacher wrote: > Am Mi., 21. Juli 2021 um 04:54 Uhr schrieb Gao Xiang > : > > Hi Andreas, > > > > On Wed, Jul 21, 2021 at 04:26:47AM +0200, Andreas Grünbacher wrote: > > > Am Mi., 21. Juli 2021 um 02:33 Uhr schrieb Gao Xiang > > > : > > > > > And since you can only kmap one page at a time, an inline read grabs the > > > > > first part of the data in "page one" and then we have to call > > > > > iomap_begin a second time get a new address so that we can read the rest > > > > > from "page two"? > > > > > > > > Nope, currently EROFS inline data won't cross page like this. > > > > > > > > But in principle, yes, I don't want to limit it to the current > > > > EROFS or gfs2 usage. I think we could make this iomap function > > > > more generally (I mean, I'd like to make the INLINE extent > > > > functionity as general as possible, > > > > > > Nono. Can we please limit this patch what we actually need right now, > > > and worry about extending it later? > > > > Can you elaborate what it will benefit us if we only support one tail > > block for iomap_read_inline_data()? (I mean it has similar LOC changes, > > similar implementation / complexity.) The only concern I think is if > > it causes gfs2 regression, so that is what I'd like to confirm. > > iomap_read_inline_data supports one inline page now (i.e., from the > beginning of the file). It seems that you don't need more than one > tail page in EROFS, right? > > You were speculating about inline data in the middle of a file. That > sounds like a really, really bad idea to me, and I don't think we > should waste any time on it. Huh? why do you think it's a bad idea? I could give real example to you. At least, it can be used for some encoded data or repeated pattern (such as AABBAABBAABB...) in a packed way (marked in extent metadata). Is that enough? Again, I don't see what the benefits if limiting it to one tail block, it (maybe) just modifies: + /* handle tail-packing blocks cross the current page into the next */ + size = min_t(unsigned int, iomap->length + pos - iomap->offset, + PAGE_SIZE - poff); to + size = min_t(unsigned int, i_blocksize(inode), + PAGE_SIZE - poff); And which has the similar complexity, so why not using iomap->length here instead? Thanks, Gao Xiang