Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1534984ybb; Thu, 26 Mar 2020 02:35:56 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsgzcTtgObckYpQJqIEvbJYBfUDoecw7STYMk4o01OuWxioolbtR9bWBeWEV58rRPV/zGhp X-Received: by 2002:aca:ad88:: with SMTP id w130mr1195869oie.82.1585215355895; Thu, 26 Mar 2020 02:35:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585215355; cv=none; d=google.com; s=arc-20160816; b=C7EHXQ2t2i/ejzdmGtmV5JJCRPt6FFlJ1SIBpR4hVdY5146so/rkZo7dL54faMGSgd XQmqW9dryp/g/NIJsv9Vw24hfSlM0IHtgLo/XPHDsbuFL9xrXViYByBGp4HihLzZyFkA M94jR23kfV5Qep58nppEseHvhTXIEm4F7Ropw6jydB0MuwGO4j0qEPHeujJ88Q1KOWqi tFEj6FARHDsg8TwSvnIapvrXl4mHPAy+dcc9K0dUohzI6SgULPWVEnYp0Mk1hJ3b44Qb zFohHIdZ1VCR4tpxWDm9GL0s9gGYpDY7h1T8LSXzL84HjQCCLgclDoXUc8JaVuViePaA 6j9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=1Dgk26+ga1imxVl88UdJNYF/M7NFE95vSbj0YEIPx7c=; b=FAh5RXRTq3ZW2F4Gd3MkCD5CgnplZN4+8F4AZX7tZG94NI7I5pub5bAOgWxBuH0pFR Mf8QAQNQGExTCnHgfG14eS7YL2we5M0jVCgET8in55dGkz0enzHh6fIcOXqLwM1lfFpj CM/VeeYd5YU0E8uzX/km/xxqXYWrXkw2AD7Bndas1Se6BwgdtLTOsC6g4T5XeLI0ZcaD Kze2vJRH5ZzeFZMeslr1M7Wzf5CVnmY3RcXDIjpfaZKXUx91yycqY1Ons8hV+/HFyUV9 eMyQytvMZM+btenOTTF4gEsDoKL7Yr0U6i8mhxSeNZ9ZrNd39cxYqkaIv8jQKOrkXi+N kh7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 r82si826436oia.155.2020.03.26.02.35.43; Thu, 26 Mar 2020 02:35:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727842AbgCZJfL (ORCPT + 99 others); Thu, 26 Mar 2020 05:35:11 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:12197 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726540AbgCZJfL (ORCPT ); Thu, 26 Mar 2020 05:35:11 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 7644EDB1CEFD789CD5B1; Thu, 26 Mar 2020 17:35:08 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 26 Mar 2020 17:35:04 +0800 Subject: Re: [PATCH RFC] f2fs: don't inline compressed inode To: Jaegeuk Kim CC: , , References: <20200325092754.63411-1-yuchao0@huawei.com> <20200325155806.GC65658@google.com> From: Chao Yu Message-ID: <87d715d0-a5c4-7b54-95bb-9b627d163271@huawei.com> Date: Thu, 26 Mar 2020 17:35:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200325155806.GC65658@google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/3/25 23:58, Jaegeuk Kim wrote: > On 03/25, Chao Yu wrote: >> f2fs_may_inline_data() only check compressed flag on current inode >> rather than on parent inode, however at this time compressed flag >> has not been inherited yet. > > When write() or other allocation happens, it'll be reset. Yeah, all tests are fine w/o this RFC patch, anyway, will let you know if I find something incompatible. Thanks, > >> >> Signed-off-by: Chao Yu >> --- >> >> Jaegeuk, >> >> I'm not sure about this, whether inline_data flag can be compatible with >> compress flag, thoughts? >> >> fs/f2fs/namei.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c >> index f54119da2217..3807d1b4c4bc 100644 >> --- a/fs/f2fs/namei.c >> +++ b/fs/f2fs/namei.c >> @@ -86,7 +86,8 @@ static struct inode *f2fs_new_inode(struct inode *dir, umode_t mode) >> if (test_opt(sbi, INLINE_XATTR)) >> set_inode_flag(inode, FI_INLINE_XATTR); >> >> - if (test_opt(sbi, INLINE_DATA) && f2fs_may_inline_data(inode)) >> + if (test_opt(sbi, INLINE_DATA) && f2fs_may_inline_data(inode) && >> + !f2fs_compressed_file(dir)) >> set_inode_flag(inode, FI_INLINE_DATA); >> if (f2fs_may_inline_dentry(inode)) >> set_inode_flag(inode, FI_INLINE_DENTRY); >> -- >> 2.18.0.rc1 > . >