Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1341586ybg; Wed, 29 Jul 2020 11:34:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxaqeCwEia4OlvuitA6/VUNsoBZJ+iPCrVAQWD1FQQOQ8qlioTCgkHnFpHoZMszCeOYFlqj X-Received: by 2002:a17:906:6b86:: with SMTP id l6mr17484919ejr.422.1596047643023; Wed, 29 Jul 2020 11:34:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596047643; cv=none; d=google.com; s=arc-20160816; b=NKcdBdL+goBOohE13mQFV0sT5nODRe3c8gZ101AeSmx/PLCw8XqkXTv6qAIvNYS7oK 0WZBVFJKPvALg/5xpbKjAXM7rkToOm32wrZfAX+LypFkSvpdQfZCUp2eRhObKUDptMo4 wsEgT4DwA1EO9Rm4HEiv6CGmxx58Ph3zvcKTJJLnv0xaRxIBjm85KbQSXvW3sCl+0fSK sY5htMXEfDquQWspPtkk/apKsYhRKUDojfUh76rVjvuZKFmhtfre9eOr1kR7irlfw1Op 9gyC+e69zHqfiSuffG+5OtZdXe//NUfuNwXTGVobhCc9aN11ofTxaKSt4uPbRg397OMl vJIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:subject :from:to:dkim-signature; bh=sbuGzfAXEu90/mb1KxvRVFNTEav+wJBHiGDp7KYLn/o=; b=RUJ3v4IT46Or+M5tUdcOghQwScSpALK2fmZ97AXGkgL1wseKqgy6QF5UVbgyPkSeWi /dvx9Mk8e3/W5Knvm88THHOBJ+Mq1YbpwtJF59ZFx4D+S69BTkdVWmCVoXA3NZC1+GjW phEb+F6hLTQfBTBRAbhrVnH+XQloDngJadoRYSv64sM5JoW4y2nyJxJBtq+lblfB1F3T 5JmRKkiKBWt0G0W4mEb3xAKbZxZ1IY8fl+ZNfv/D+ZNHO/hXJqRLeTCIIAFrvGKSqbgX b1WZJnGFfyCcHzJE+NFF8+/oRwTXQ3yQ35TMmJtRG0Yoj1p1KWdD347e6XCrLSlxAkJ6 rzmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=d5pNoGKh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bi20si1549757ejb.365.2020.07.29.11.33.40; Wed, 29 Jul 2020 11:34:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=d5pNoGKh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727811AbgG2Sce (ORCPT + 99 others); Wed, 29 Jul 2020 14:32:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726496AbgG2Scd (ORCPT ); Wed, 29 Jul 2020 14:32:33 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DF2DC061794 for ; Wed, 29 Jul 2020 11:32:33 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id o22so18157295qtt.13 for ; Wed, 29 Jul 2020 11:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=sbuGzfAXEu90/mb1KxvRVFNTEav+wJBHiGDp7KYLn/o=; b=d5pNoGKhhZSJ1U2hnE2QgpyNRXyWdy5CzWssvK8e5m9UCWTFT3DivPdKlbrS8Lhroy Q+Ory2dwx+5FMcg7WGADmy37Sw80SSCn2qGAfb13yHemobrCV+gw8VUpmnCGBjL4n05s t9vW7n0M+ALckESz1KTapB8in/rEyUPPlhWZAQWW9L7UaLdOC/j006FGs35FQyfELq0l sNyJUc3f1oWkgh26+VHo9fdtS3+R0gHjhwfo7g1dxsI9NCuf7/+gW7AmKLSVcVYQVnkv wDCBysP/09LebzKqgezyGw9u5rd3sTnRHKdxfCgJxbKw+AikBNsNeN0ymqK+7U+NzQvO UW5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=sbuGzfAXEu90/mb1KxvRVFNTEav+wJBHiGDp7KYLn/o=; b=OST6jUDnK20TkUKVemvZa08453UHOt4k0ieFbdCIKIW2TenWv8rlIuLss/1Mw3kPsb FxwwCLbAaabd53KlKS/2LuweFf+O86THgyB3xfAIG2VoYxZ3cWS92Ht+qdX03w59YAp8 6YvIt4nm5wTH5/Ktbzzy/I7l7SlMcx50NDR1VAlUEJATINSgj1g87V2lu1RjrnfaMo9e vrWC8uvWChZS9WiSGQ0L/VOtuObd3Hf5nZSv9u2ndRMOsPCm4QuW9QPpOSgdxhP7KLGg 6u7aCioiBdXziYPC38VPOvReQtnLh0/sW2ke7zY/7uAUUf3KqRsp89g+YMkELFoebgUv aP0A== X-Gm-Message-State: AOAM5334BMP1YAJQOE+ThmDa33dmr0qAB4Tec6LCMWrW/Fea7irQVLRo CbuBayb2HkPFAa6khflixDZvYw== X-Received: by 2002:ac8:478f:: with SMTP id k15mr32939604qtq.287.1596047552340; Wed, 29 Jul 2020 11:32:32 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:11e1::10a7? ([2620:10d:c091:480::1:2ed9]) by smtp.gmail.com with ESMTPSA id l64sm2118053qkc.21.2020.07.29.11.32.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2020 11:32:31 -0700 (PDT) To: Linus Torvalds , David Howells , Al Viro , Eric Sandeen , Christoph Hellwig , Linux Kernel Mailing List , Linux FS Devel , David Sterba From: Josef Bacik Subject: Inverted mount options completely broken (iversion,relatime) Message-ID: <0b154b9b-728f-7d57-d4c5-ec25fc9dfdf3@toxicpanda.com> Date: Wed, 29 Jul 2020 14:32:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Eric reported a problem to me where we were clearing SB_I_VERSION on remount of a btrfs file system. After digging through I discovered it's because we expect the proper flags that we want to be passed in via the mount() syscall, and because we didn't have "iversion" in our show_options entry the mount binary (form util-linux) wasn't setting MS_I_VERSION for the remount, and thus the VFS was clearing SB_I_VERSION from our s_flags. No big deal, I'll fix show_mount. Except Eric then noticed that mount -o noiversion didn't do anything, we still get iversion set. That's because btrfs just defaults to having SB_I_VERSION set. Furthermore -o noiversion doesn't get sent into mount, it's handled by the mount binary itself, and it does this by not having MS_I_VERSION set in the mount flags. This happens as well for -o relatime, it's the default and so if you do mount -o norelatime it won't do anything, you still get relatime behavior. The only time this changes is if you do mount -o remount,norelatime. So my question is, what do we do here? I know Christoph has the strong opinion that we just don't expose I_VERSION at all, which frankly I'm ok with. However more what I'm asking is what do we do with these weird inverted flags that we all just kind of ignore on mount? The current setup is just broken if we want to allow overriding the defaults at mount time. Are we ok with it just being broken? Are we ok with things like mount -o noiversion not working because the file system has decided that I_VERSION (or relatime) is the default, and we're going to ignore what the user asks for unless we're remounting? Thanks, Josef