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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 DA330C3A59F for ; Thu, 29 Aug 2019 11:29:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7EA52173E for ; Thu, 29 Aug 2019 11:29:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727963AbfH2L30 (ORCPT ); Thu, 29 Aug 2019 07:29:26 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:3540 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726379AbfH2L30 (ORCPT ); Thu, 29 Aug 2019 07:29:26 -0400 Received: from DGGEMM403-HUB.china.huawei.com (unknown [172.30.72.57]) by Forcepoint Email with ESMTP id AAFEA3C849874D2B6330; Thu, 29 Aug 2019 19:29:24 +0800 (CST) Received: from dggeme762-chm.china.huawei.com (10.3.19.108) by DGGEMM403-HUB.china.huawei.com (10.3.20.211) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 29 Aug 2019 19:29:23 +0800 Received: from architecture4 (10.140.130.215) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 29 Aug 2019 19:29:20 +0800 Date: Thu, 29 Aug 2019 19:28:33 +0800 From: Gao Xiang To: Christoph Hellwig CC: Alexander Viro , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Theodore Ts'o , "Pavel Machek" , David Sterba , Amir Goldstein , "Darrick J . Wong" , "Dave Chinner" , Jaegeuk Kim , Jan Kara , Linus Torvalds , , , LKML , , Chao Yu , Miao Xie , Li Guifu , Fang Wei Subject: Re: [PATCH v6 08/24] erofs: add namei functions Message-ID: <20190829112833.GE64893@architecture4> References: <20190802125347.166018-1-gaoxiang25@huawei.com> <20190802125347.166018-9-gaoxiang25@huawei.com> <20190829102838.GG20598@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190829102838.GG20598@infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.140.130.215] X-ClientProxiedBy: dggeme708-chm.china.huawei.com (10.1.199.104) To dggeme762-chm.china.huawei.com (10.3.19.108) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 29, 2019 at 03:28:38AM -0700, Christoph Hellwig wrote: > On Fri, Aug 02, 2019 at 08:53:31PM +0800, Gao Xiang wrote: > > +struct erofs_qstr { > > + const unsigned char *name; > > + const unsigned char *end; > > +}; > > Maybe erofs_name? The q in qstr stands for quick, because of the > existing hash and len, which this doesn't really provide. > > Also I don't really see why you don't just pass the actual qstr and > just document that dirnamecmp does not look at the hash and thus > doesn't require it to be filled out. q in erofs_qstr also means quick substring. If you have some time to look into it more, it uses a prefixed binary search algorithm (rather than linear traversal), which provides similar proformance with hashed approach but no need to save such hash field and it's natively sorted in alphabet order. Thanks, Gao Xiang >