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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E841EB64DA for ; Wed, 5 Jul 2023 07:55:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232376AbjGEHz6 (ORCPT ); Wed, 5 Jul 2023 03:55:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230385AbjGEHzw (ORCPT ); Wed, 5 Jul 2023 03:55:52 -0400 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8476E6B for ; Wed, 5 Jul 2023 00:55:50 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R431e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0VmfoNa4_1688543745; Received: from 30.97.48.243(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0VmfoNa4_1688543745) by smtp.aliyun-inc.com; Wed, 05 Jul 2023 15:55:46 +0800 Message-ID: Date: Wed, 5 Jul 2023 15:55:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 2/2] erofs: boost negative xattr lookup with bloom filter To: Alexander Larsson , Jingbo Xu Cc: chao@kernel.org, huyue2@coolpad.com, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20230705070427.92579-1-jefflexu@linux.alibaba.com> <20230705070427.92579-3-jefflexu@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/7/5 15:44, Alexander Larsson wrote: > On Wed, Jul 5, 2023 at 9:04 AM Jingbo Xu wrote: ... >> + if (erofs_sb_has_xattr_filter(sbi)) { > > As I said in my other mail. I would really like this to just always do > the filter check. It should be safe as older fs:es have zero in place > here, and doing this allows me to create composefs images with the > bloom filters that also work with older kernels. As my previous email, this flag is on-disk compatible which means old unsupported kernels will just ignore this and go on mounting. But this flag indicates a new on-disk feature in the image anyway, users could know if an image uses the new feature rather than seek to individual inodes. Does it sound reasonable or some other consideration? 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B1AB1EB64DD for ; Wed, 5 Jul 2023 07:55:56 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QwsRH1Qmcz30gr for ; Wed, 5 Jul 2023 17:55:55 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.alibaba.com (client-ip=115.124.30.133; helo=out30-133.freemail.mail.aliyun.com; envelope-from=hsiangkao@linux.alibaba.com; receiver=lists.ozlabs.org) Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 4QwsRC2sJSz301T for ; Wed, 5 Jul 2023 17:55:50 +1000 (AEST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R431e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0VmfoNa4_1688543745; Received: from 30.97.48.243(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0VmfoNa4_1688543745) by smtp.aliyun-inc.com; Wed, 05 Jul 2023 15:55:46 +0800 Message-ID: Date: Wed, 5 Jul 2023 15:55:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 2/2] erofs: boost negative xattr lookup with bloom filter To: Alexander Larsson , Jingbo Xu References: <20230705070427.92579-1-jefflexu@linux.alibaba.com> <20230705070427.92579-3-jefflexu@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, huyue2@coolpad.com Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On 2023/7/5 15:44, Alexander Larsson wrote: > On Wed, Jul 5, 2023 at 9:04 AM Jingbo Xu wrote: ... >> + if (erofs_sb_has_xattr_filter(sbi)) { > > As I said in my other mail. I would really like this to just always do > the filter check. It should be safe as older fs:es have zero in place > here, and doing this allows me to create composefs images with the > bloom filters that also work with older kernels. As my previous email, this flag is on-disk compatible which means old unsupported kernels will just ignore this and go on mounting. But this flag indicates a new on-disk feature in the image anyway, users could know if an image uses the new feature rather than seek to individual inodes. Does it sound reasonable or some other consideration? Thanks, Gao Xiang