From: Amir Goldstein <amir73il@gmail.com>
To: Chris Down <chris@chrisdown.name>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Jeff Layton <jlayton@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
kernel-team@fb.com, Hugh Dickins <hughd@google.com>,
"zhengbin (A)" <zhengbin13@huawei.com>,
Linux MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 0/2] fs: inode: shmem: Reduce risk of inum overflow
Date: Sat, 4 Jan 2020 23:16:04 +0200 [thread overview]
Message-ID: <CAOQ4uxhC6L6whNyc6bs99ZcMRxMOt5xNR0HMKmJ8w1thXgO+zw@mail.gmail.com> (raw)
In-Reply-To: <cover.1578072481.git.chris@chrisdown.name>
On Fri, Jan 3, 2020 at 7:30 PM Chris Down <chris@chrisdown.name> 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.
parent reply other threads:[~2020-01-04 21:16 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <cover.1578072481.git.chris@chrisdown.name>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOQ4uxhC6L6whNyc6bs99ZcMRxMOt5xNR0HMKmJ8w1thXgO+zw@mail.gmail.com \
--to=amir73il@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris@chrisdown.name \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jlayton@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=zhengbin13@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox