• Chris Down's avatar
    tmpfs: per-superblock i_ino support · e809d5f0
    Chris Down authored
    Patch series "tmpfs: inode: Reduce risk of inum overflow", v7.
    
    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/
    
    This patch (of 2):
    
    get_next_ino has a number of problems:
    
    - It uses and returns a uint, which is susceptible to become overflowed
      if a lot of volatile inodes that use get_next_ino are created.
    - It's global, with no specificity per-sb or even per-filesystem. This
      means it's not that difficult to cause inode number wraparounds on a
      single device, which can result in having multiple distinct inodes
      with the same inode number.
    
    This patch adds a per-superblock counter that mitigates the second case.
    This design also allows us to later have a specific i_ino size per-device,
    for example, allowing users to choose whether to use 32- or 64-bit inodes
    for each tmpfs mount.  This is implemented in the next commit.
    
    For internal shmem mounts which may be less tolerant to spinlock delays,
    we implement a percpu batching scheme which only takes the stat_lock at
    each batch boundary.
    Signed-off-by: default avatarChris Down <chris@chrisdown.name>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Acked-by: default avatarHugh Dickins <hughd@google.com>
    Cc: Amir Goldstein <amir73il@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Jeff Layton <jlayton@kernel.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Tejun Heo <tj@kernel.org>
    Link: http://lkml.kernel.org/r/cover.1594661218.git.chris@chrisdown.name
    Link: http://lkml.kernel.org/r/1986b9d63b986f08ec07a4aa4b2275e718e47d8a.1594661218.git.chris@chrisdown.nameSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    e809d5f0
shmem_fs.h 5.09 KB