lkml.org 
[lkml]   [2020]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 2/2] tmpfs: Support 64-bit inums per-sb
    On Fri, 10 Jan 2020, Chris Down wrote:
    > Hugh Dickins writes:
    > > Dave, Amir, Chris, many thanks for the info you've filled in -
    > > and absolutely no need to run any scan on your fleet for this,
    > > I think we can be confident that even if fb had some 15-year-old tool
    > > in use on its fleet of 2GB-file filesystems, it would not be the one
    > > to insist on a kernel revert of 64-bit tmpfs inos.
    > >
    > > The picture looks clear now: while ChrisD does need to hold on to his
    > > config option and inode32/inode64 mount option patch, it is much better
    > > left out of the kernel until (very unlikely) proved necessary.
    >
    > Based on Mikael's comment above about Steam binaries, and the lack of
    > likelihood that they can be rebuilt, I'm inclined to still keep inode{64,32},
    > but make legacy behaviour require explicit opt-in. That is:
    >
    > - Default it to inode64
    > - Remove the Kconfig option
    > - Only print it as an option if tmpfs was explicitly mounted with inode32
    >
    > The reason I suggest keeping this is that I'm mildly concerned that the kind
    > of users who might be impacted by this change due to 32-bit _FILE_OFFSET_BITS
    > -- like the not-too-uncommon case that Mikael brings up -- seem unlikely to
    > be the kind of people that would find it in an rc.

    Okay. None of us are thrilled with it, but I agree that
    Mikael's observation should override our developer's preference.

    So the "inode64" option will be accepted but redundant on mounting,
    but exists for use as a remount option after mounting or remounting
    with "inode32": allowing the admin to switch temporarily to mask off
    the high ino bits with "inode32" when needing to run a limited binary.

    Documentation and commit message to alert Andrew and Linus and distros
    that we are risking some breakage with this, but supplying the antidote
    (not breakage of any distros themselves, no doubt they're all good;
    but breakage of what some users might run on them).

    >
    > Other than that, the first patch could be similar to how it is now,
    > incorporating Hugh's improvements to the first patch to put everything under
    > the same stat_lock in shmem_reserve_inode.

    So, I persuaded Amir to the other aspects my version, but did not
    persuade you? Well, I can live with that (or if not, can send mods
    on top of yours): but please read again why I was uncomfortable with
    yours, to check that you still prefer it (I agree that your patch is
    simpler, and none of my discomfort decisive).

    Thanks,
    Hugh

    \
     
     \ /
      Last update: 2020-01-13 08:36    [W:3.914 / U:1.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site