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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 1E5D2C43215 for ; Thu, 21 Nov 2019 20:07:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4DF02070B for ; Thu, 21 Nov 2019 20:07:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WWaVFGqW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4DF02070B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5460E6B0378; Thu, 21 Nov 2019 15:07:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D27B6B0379; Thu, 21 Nov 2019 15:07:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BFF16B037A; Thu, 21 Nov 2019 15:07:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id 22C366B0378 for ; Thu, 21 Nov 2019 15:07:48 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id BFAC8181AEF07 for ; Thu, 21 Nov 2019 20:07:47 +0000 (UTC) X-FDA: 76181370174.20.cry54_7e379ab9bb442 X-HE-Tag: cry54_7e379ab9bb442 X-Filterd-Recvd-Size: 4831 Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 Nov 2019 20:07:47 +0000 (UTC) Received: by mail-pj1-f68.google.com with SMTP id m71so1969887pjb.12 for ; Thu, 21 Nov 2019 12:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=7gJkYA2Ya9RG5lGDwn1afx4TWUN9AxI8xhu9u772h5Y=; b=WWaVFGqW2/oLxe+xGDL8ESIk7ySRmIkSvNHhrf3ay4rMeCqCreUEnGYrb3YqkcRzo4 yRUMbJqjYpaWyd/M3ApB49phxSn22Tkt/DEwr2CVkF2PVed8jfyG2lSW7K3zDd33oJzF tQIOItlo/zsfuWmI7lb647H81Tr6LFN6RYD/3JCGBtVLLR6G5aPrpY6ZapVYE9oA/qPW a7wk3oS+mOfc0L7UWgYe3GNkXEndoeAsEE1wla1/BHD9tneTq8XfW6orHSB6TWBr3KUp TLHs6XQA789q2a8MMiZtp/LM3c06I0HNlkUd1vXg2LJ2ukqy+jS41qevVnmv5kaV1rsg 3/zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=7gJkYA2Ya9RG5lGDwn1afx4TWUN9AxI8xhu9u772h5Y=; b=KjF0K/KZrJy1uMxD9ETJ2321EwUfB1Hg+EAjNbfnDjdjXfMYwLDNzktEHydHLiZ9r8 +sV51p8DAdOzCoNFGtt1i17E7LRZ5h5kWDoNPzANCHNb2IPFxyAQo2eJFsoFaW6hqsOK bd98zuQ8nSWDwlK5LAzVVMY0OINRylnGI+qHIvA43joFgeNDZpRZTL1d2jWAvQLMbn8E pQE5gJa4mMXYbQGilf/TVybVK33LqIf/u+RB7+k9haCyOZG5i9y5pQ5DA7g1IqvCmoDV TC39NqPS0iKBiWzOP5m8Ii03eyyAGWpgglhVYs3yM2XRjTSujYU1XgNuZsEQp0NNHrYe IGNA== X-Gm-Message-State: APjAAAX29MuXOQeYFoaSR5LWIu06Qrw7URj4/5xE7W2o6406TmZD8+aK YAbCj9DMkxE2fHhIaqBdJPgvOg== X-Google-Smtp-Source: APXvYqxUxbUKUpPLEZrPIO8I4uqq5S/MzKrg3wGpWFWZ9doKJbjnTEvfxpwZYA7Jy5jZgjH0PX8+tg== X-Received: by 2002:a17:902:8502:: with SMTP id bj2mr10719141plb.303.1574366865400; Thu, 21 Nov 2019 12:07:45 -0800 (PST) Received: from [100.112.92.218] ([104.133.9.106]) by smtp.gmail.com with ESMTPSA id b24sm4411116pfi.148.2019.11.21.12.07.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Nov 2019 12:07:44 -0800 (PST) Date: Thu, 21 Nov 2019 12:07:43 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: "J. R. Okajima" cc: Hugh Dickins , "zhengbin (A)" , Matthew Wilcox , viro@zeniv.linux.org.uk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, houtao1@huawei.com, yi.zhang@huawei.com Subject: Re: [PATCH] tmpfs: use ida to get inode number In-Reply-To: <32188.1574336426@jrobl> Message-ID: References: <1574259798-144561-1-git-send-email-zhengbin13@huawei.com> <20191120154552.GS20752@bombadil.infradead.org> <1c64e7c2-6460-49cf-6db0-ec5f5f7e09c4@huawei.com> <32188.1574336426@jrobl> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 21 Nov 2019, J. R. Okajima wrote: > Hugh Dickins: > > Internally (in Google) we do rely on good tmpfs inode numbers more > > than on those of other get_next_ino() filesystems, and carry a patch > > to mm/shmem.c for it to use 64-bit inode numbers (and separate inode > > number space for each superblock) - essentially, > > > > =09ino =3D sbinfo->next_ino++; > > =09/* Avoid 0 in the low 32 bits: might appear deleted */ > > =09if (unlikely((unsigned int)ino =3D=3D 0)) > > =09=09ino =3D sbinfo->next_ino++; > > I agree with that "per superblock inum space", but I don't see your > point. How can you manage it fully? I mean how can you decide whether > the new inum is in use or not? > For example, > - you create a file which is assigned inum#10. > - you or other people create and unlink over and over on the same tmpfs. > - then sbinfo->next_ino will become zero, skipped, ok. > - and then it will be 10. > I don't think you want to share the same inum by two inodes. 64 bits. I haven't done the arithmetic to work out the amusing number, but zhengbin mentioned the script taking 10 days to duplicate an inode number in 32 bits, so: a larger number of years than I need to care about. > > Moreover, SysV SHM uses tmpfs and shmget(2) overwrite inum internally. > It will be another seed of a similar problem. I was totally ignorant of that peculiarity in ipc/shm.c, thanks for alerting me to it. But it doesn't affect what we're doing in tmpfs, and apparently suits the users of SysV SHM: I don't see any need to worry about it. Hugh