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=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 27A51C33C99 for ; Sat, 4 Jan 2020 21:16:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E0BD724653 for ; Sat, 4 Jan 2020 21:16:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H0NUm63m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E0BD724653 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7724E8E0005; Sat, 4 Jan 2020 16:16:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 721788E0003; Sat, 4 Jan 2020 16:16:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6378C8E0005; Sat, 4 Jan 2020 16:16:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 4ECD48E0003 for ; Sat, 4 Jan 2020 16:16:17 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id EF6F045A8 for ; Sat, 4 Jan 2020 21:16:16 +0000 (UTC) X-FDA: 76341209952.23.snake80_53e65a31dd00c X-HE-Tag: snake80_53e65a31dd00c X-Filterd-Recvd-Size: 5518 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Sat, 4 Jan 2020 21:16:16 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id z8so44738583ioh.0 for ; Sat, 04 Jan 2020 13:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=snCBX0j5ay9kgj6iZfPL2/aocexXLHXt8hsG7KfcQKY=; b=H0NUm63m1Oa+7DyTVnNJc/PlM5/UteN16n7bvwASZASu8wmJEzHg97yJ9jNyu1JFys UEzWGhX7D2cAUsw5lwf9q3KwM+AC1hFNyQDDuycsUAWzJJRQsE/aTrfnr43420ebgOoz Tf5v9J6K/Lu2NiafplulCkrh42anLxLtoTjRkve4VnLzO/EBakjavSFufAfk9gDamY/f TFMKQvcXqoU6ustmDPPDEsB9mgp+EzplBKZtpOUIL2emCqu4Lu6agAWcf6RG8uYMLQCh MWI5+wZ1pA2/SHfxX/y/jyFugDX0duj0BoayGr6n8r/dulX03T5djGNYVJwmvFQBwKrx m51Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=snCBX0j5ay9kgj6iZfPL2/aocexXLHXt8hsG7KfcQKY=; b=RtNPoYCeKWAGCSsGKKz6zXrScCOx2iLym3Zd1VvoudYvprR5mvZixSHP7ZawejmQnX eOpwgszjc/eeEQaDDs+Sy/TPFioUpclFa7cKoxjkGrtDNOGkAE0juDJvNhsWinDXwfSl G7TgC268kDUx7VysACpH9BQ4QgegRJwYqsSxYuWa7dep8Lmc5WS4A43ZL063DRsizcjm nt5arVCY2Q7BxgVKij1P6wUwLnDBFnySbEOh8VdNY2th26W5PAn+U/wdKdQSVJh1Vxun ex4GQOGy3xlFp+a3yrGPsI8BuoeBsdReD6p9sHNYdGwt6SHVF4jD4G1rmjvA2xEQBxzL cxXQ== X-Gm-Message-State: APjAAAUQbIqL4sLi5bIIRWsKi5rAQr7TeBewd/pajqq8hkKZQVNY6kcx HejnlXvF+sJ2l2Lh3t8lAttXyfSveqPWelCU5PY= X-Google-Smtp-Source: APXvYqwpNX0oJAGFb7plxGj+mrk/pVD85S5jglSWMAHsjkX180fee7do9kPBZ3lFzsuac3e1xHxfVdTrHJ0kodA7IoQ= X-Received: by 2002:a6b:5904:: with SMTP id n4mr65813651iob.9.1578172575756; Sat, 04 Jan 2020 13:16:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amir Goldstein Date: Sat, 4 Jan 2020 23:16:04 +0200 Message-ID: Subject: Re: [PATCH v3 0/2] fs: inode: shmem: Reduce risk of inum overflow To: Chris Down Cc: linux-fsdevel , Al Viro , Matthew Wilcox , Jeff Layton , Johannes Weiner , Tejun Heo , linux-kernel , kernel-team@fb.com, Hugh Dickins , "zhengbin (A)" , Linux MM , Andrew Morton Content-Type: text/plain; charset="UTF-8" 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 Fri, Jan 3, 2020 at 7:30 PM Chris Down wrote: > > In Facebook production we are seeing heavy i_ino wraparounds on tmpfs. > On affected tiers, in excess of 10% of hosts show multiple files with > different content and the same inode number, with some servers even > having as many as 150 duplicated inode numbers with differing file > content. > > This causes actual, tangible problems in production. For example, we > have complaints from those working on remote caches that their > application is reporting cache corruptions because it uses (device, > inodenum) to establish the identity of a particular cache object, but > because it's not unique any more, the application refuses to continue > and reports cache corruption. Even worse, sometimes applications may not > even detect the corruption but may continue anyway, causing phantom and > hard to debug behaviour. > > In general, userspace applications expect that (device, inodenum) should > be enough to be uniquely point to one inode, which seems fair enough. > One might also need to check the generation, but in this case: > > 1. That's not currently exposed to userspace > (ioctl(...FS_IOC_GETVERSION...) returns ENOTTY on tmpfs); > 2. Even with generation, there shouldn't be two live inodes with the > same inode number on one device. > > In order to mitigate this, we take a two-pronged approach: > > 1. Moving inum generation from being global to per-sb for tmpfs. This > itself allows some reduction in i_ino churn. This works on both 64- > and 32- bit machines. > 2. Adding inode{64,32} for tmpfs. This fix is supported on machines with > 64-bit ino_t only: we allow users to mount tmpfs with a new inode64 > option that uses the full width of ino_t, or CONFIG_TMPFS_INODE64. > > Chris Down (2): > tmpfs: Add per-superblock i_ino support > tmpfs: Support 64-bit inums per-sb > > Documentation/filesystems/tmpfs.txt | 11 ++++ > fs/Kconfig | 15 +++++ > include/linux/shmem_fs.h | 2 + > mm/shmem.c | 97 ++++++++++++++++++++++++++++- > 4 files changed, 124 insertions(+), 1 deletion(-) > CC tmpfs maintainer, linux-mm and Andrew Morton, who is the one sending most of the tmpfs patches to Linus. Also worth mentioning these previous attempts by zhengbin, which was trying to address the same problem without the per-sb ino counter approach: https://patchwork.kernel.org/patch/11254001/ https://patchwork.kernel.org/patch/11023915/ Thanks, Amir.