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.2 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 7B63DC432C0 for ; Thu, 21 Nov 2019 02:36:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F17EB2075A for ; Thu, 21 Nov 2019 02:36:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F17EB2075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 636526B029F; Wed, 20 Nov 2019 21:36:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E6ED6B02A0; Wed, 20 Nov 2019 21:36:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FD1C6B02A1; Wed, 20 Nov 2019 21:36:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 397D86B029F for ; Wed, 20 Nov 2019 21:36:43 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 134EE52C1 for ; Thu, 21 Nov 2019 02:36:43 +0000 (UTC) X-FDA: 76178721486.20.coast05_7480925c2c85b X-HE-Tag: coast05_7480925c2c85b X-Filterd-Recvd-Size: 3637 Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 Nov 2019 02:36:40 +0000 (UTC) Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id D29A86C6613290C8A35D; Thu, 21 Nov 2019 10:36:34 +0800 (CST) Received: from [127.0.0.1] (10.184.213.217) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.439.0; Thu, 21 Nov 2019 10:36:06 +0800 Subject: Re: [PATCH] tmpfs: use ida to get inode number To: Matthew Wilcox CC: , , , , , References: <1574259798-144561-1-git-send-email-zhengbin13@huawei.com> <20191120154552.GS20752@bombadil.infradead.org> From: "zhengbin (A)" Message-ID: <1c64e7c2-6460-49cf-6db0-ec5f5f7e09c4@huawei.com> Date: Thu, 21 Nov 2019 10:36:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20191120154552.GS20752@bombadil.infradead.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US X-Originating-IP: [10.184.213.217] X-CFilter-Loop: Reflected Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2019/11/20 23:45, Matthew Wilcox wrote: > On Wed, Nov 20, 2019 at 10:23:18PM +0800, zhengbin wrote: >> I have tried to change last_ino type to unsigned long, while this was >> rejected, see details on https://patchwork.kernel.org/patch/11023915. > Did you end up trying sbitmap? Maybe sbitmap is not a good solution, max_inodes of tmpfs are controlled = by mount options--nrinodes, which can be modified by remountfs(bigger or smaller), as the comment of = function sbitmap_resize says: =C2=A0* Doesn't reallocate anything. It's up to the caller to ensure that= the new =C2=A0* depth doesn't exceed the depth that the sb was initialized with. We can modify this to meet the growing requirements, there will still be = questions as follows: 1. tmpfs is a ram filesystem, we need to allocate sbitmap memory for sbin= fo->max_inodes(while this maybe huge) 2.If remountfs changes=C2=A0 max_inode, we have to deal with it, while th= is may take a long time (bigger: we need to free the old sbitmap memory, allocate new memory, cop= y the old sbitmap to new sbitmap smaller: How do we deal with it?ie: we use sb->map[inode number/8] to fin= d the sbitmap, we need to change the exist inode numbers?while this maybe used by userspace application.) > > What I think is fundamentally wrong with this patch is that you've foun= d a > problem in get_next_ino() and decided to use a different scheme for thi= s > one filesystem, leaving every other filesystem which uses get_next_ino(= ) > facing the same problem. > > That could be acceptable if you explained why tmpfs is fundamentally > different from all the other filesystems that use get_next_ino(), but > you haven't (and I don't think there is such a difference. eg pipes, > autofs and ipc mqueue could all have the same problem. tmpfs is same with all the other filesystems that use get_next_ino(), but= we need to solve this problem one by one. If tmpfs is ok, we can modify the other filesystems too. Besides, I do no= t=C2=A0 recommend all file systems share the same global variable, for performance impact consideration. > > There are some other problems I noticed, but they're not worth bringing > up until this fundamental design choice is justified. Agree, thanks. >