From patchwork Sun Jan 5 12:05:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Down X-Patchwork-Id: 11318177 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DC1E11398 for ; Sun, 5 Jan 2020 12:05:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A936F218AC for ; Sun, 5 Jan 2020 12:05:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="s9D99V0h" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A936F218AC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C505E8E0007; Sun, 5 Jan 2020 07:05:25 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id C02048E0003; Sun, 5 Jan 2020 07:05:25 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF0728E0007; Sun, 5 Jan 2020 07:05:25 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 985098E0003 for ; Sun, 5 Jan 2020 07:05:25 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 3AA4B8249980 for ; Sun, 5 Jan 2020 12:05:25 +0000 (UTC) X-FDA: 76343450610.16.fish21_8693154cdb51a X-Spam-Summary: 2,0,0,d9ba2648a5364552,d41d8cd98f00b204,chris@chrisdown.name,::hughd@google.com:akpm@linux-foundation.org:viro@zeniv.linux.org.uk:willy@infradead.org:amir73il@gmail.com:jlayton@kernel.org:hannes@cmpxchg.org:tj@kernel.org:linux-fsdevel@vger.kernel.org:linux-kernel@vger.kernel.org:kernel-team@fb.com,RULES_HIT:41:355:379:967:973:988:989:1260:1277:1312:1313:1314:1345:1437:1516:1518:1519:1535:1542:1593:1594:1595:1596:1711:1730:1747:1777:1792:1801:2198:2199:2393:2525:2553:2559:2564:2682:2685:2689:2731:2859:2898:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4605:5007:6119:6261:6653:6742:7875:9025:10004:10400:11026:11473:11658:11914:12043:12291:12297:12438:12517:12519:12555:12679:12895:12986:13053:13439:13895:14096:14097:14181:14394:14721:21080:21444:21451:21627:21740:21990:30034:30054:30066:30070:30090,0,RBL:209.85.221.65:@chrisdown.na me:.lbl8 X-HE-Tag: fish21_8693154cdb51a X-Filterd-Recvd-Size: 5078 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Sun, 5 Jan 2020 12:05:24 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id d16so46597296wre.10 for ; Sun, 05 Jan 2020 04:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=H1hJLNQee379aq3/tU9tTxHeBbBKoIXcCyb5gddw+z0=; b=s9D99V0hhwG8BrJ6pW+LVYSffkdsoaBLwNeOukJHDMIXgSD6bHgOQzR65WF7hdzmWF 4igDoTk2Jrc30WIXJjWsJvUibhNZACpbR9WKX7169TL7ASJL/qcm1BM/8Gb+MM4kLEe/ VlFkIr8G08H9znscjvgmDqE19S23KbBnTyYrg= 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:message-id:mime-version :content-disposition; bh=H1hJLNQee379aq3/tU9tTxHeBbBKoIXcCyb5gddw+z0=; b=UX1Ivv9lZgfT21xx1Po+hO1ZD2CSrQm4jwxibm4IUYzZiy+OBGY3u12AQABkAelq+m 8Q2D+P6YKgw2mu36y5KgxhHGxL09+39gXGB7gXfzkJVeemsDubni4lizwxKalhLF9Gne /jZHzbtUB+0KiuGx0XLD4Rgx4vs9pnrQKJCZ1ZpMfTEzPgNFxLd0bcQNYfediki0/l5N FREuwTD86n9+RgCELVqHg1LxZQBsoLyOA63j18vRydhkBglEBS9wa4eSdTVXRzPa83gx /JOtPnOe0LB6rGy3OkG5mxJWwAy1lOJ8/3UgweVw1sDSdVwBwTv0yZ5eNxzYO4zV6QsD LMsg== X-Gm-Message-State: APjAAAWE/NenvlFt8wrFdmHncsjl3EKOAi8VoJ6vDoRAfNSA05PDxaft 32TuTOF61k7s0PTnLEfx8PbuInVJLz0= X-Google-Smtp-Source: APXvYqy0G+txcVO2FRvfPrzeMAhObxnRpEQHoeswgwkjOKalPYou8MtvQe2UloqhBRZl+eSQ80pw9g== X-Received: by 2002:a5d:5403:: with SMTP id g3mr8357673wrv.302.1578225923244; Sun, 05 Jan 2020 04:05:23 -0800 (PST) Received: from localhost ([2620:10d:c092:180::1:e1d7]) by smtp.gmail.com with ESMTPSA id p5sm69068815wrt.79.2020.01.05.04.05.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2020 04:05:22 -0800 (PST) Date: Sun, 5 Jan 2020 12:05:22 +0000 From: Chris Down To: linux-mm@kvack.org Cc: Hugh Dickins , Andrew Morton , Al Viro , Matthew Wilcox , Amir Goldstein , Jeff Layton , Johannes Weiner , Tejun Heo , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v5 0/2] fs: inode: shmem: Reduce risk of inum overflow Message-ID: MIME-Version: 1.0 Content-Disposition: inline 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: 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. You can see how this compares to previous related patches which didn't implement this per-superblock: - https://patchwork.kernel.org/patch/11254001/ - https://patchwork.kernel.org/patch/11023915/ 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 | 94 ++++++++++++++++++++++++++++- 4 files changed, 121 insertions(+), 1 deletion(-)