From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 381BAC4321D for ; Thu, 16 Aug 2018 17:21:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E7A1D208A3 for ; Thu, 16 Aug 2018 17:21:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7A1D208A3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728535AbeHPUVX (ORCPT ); Thu, 16 Aug 2018 16:21:23 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:47274 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725969AbeHPUVW (ORCPT ); Thu, 16 Aug 2018 16:21:22 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fqLxj-0004nO-0o; Thu, 16 Aug 2018 11:21:31 -0600 Received: from [97.119.167.31] (helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fqLxi-0004Ug-Aw; Thu, 16 Aug 2018 11:21:30 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Steve French Cc: David Howells , trond.myklebust@hammerspace.com, Anna Schumaker , Steve French , Steve Dickson , Al Viro , Linus Torvalds , ebiederm@redhat.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel , LKML , linux-nfs@vger.kernel.org, CIFS , linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net References: <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <17763.1534350685@warthog.procyon.org.uk> <87pnyiew8x.fsf@xmission.com> Date: Thu, 16 Aug 2018 12:21:23 -0500 In-Reply-To: (Steve French's message of "Thu, 16 Aug 2018 11:24:56 -0500") Message-ID: <87in4acjn0.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1fqLxi-0004Ug-Aw;;;mid=<87in4acjn0.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.119.167.31;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18gCLRR5hyEu8VeoAcvITnRRHb6CUf2MKU= X-SA-Exim-Connect-IP: 97.119.167.31 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: Should we split the network filesystem setup into two phases? X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Steve French writes: > On Thu, Aug 16, 2018 at 2:56 AM Eric W. Biederman wrote: >> >> David Howells writes: >> >> > Having just re-ported NFS on top of the new mount API stuff, I find that I >> > don't really like the idea of superblocks being separated by communication >> > parameters - especially when it might seem reasonable to be able to adjust >> > those parameters. >> > >> > Does it make sense to abstract out the remote peer and allow (a) that to be >> > configured separately from any superblocks using it and (b) that to be used to >> > create superblocks? > >> At least for devpts we always create a new filesystem instance every >> time mount(2) is called. NFS seems to have the option to create a new >> filesystem instance every time mount(2) is called as well, (even if the >> filesystem parameters are the same). And depending on the case I can >> see the attraction for other filesystems as well. >> >> So I don't think we can completely abandon the option for filesystems >> to always create a new filesystem instance when mount(8) is called. > > In cifs we attempt to match new mounts to existing tree connections > (instances of connections to a \\server\share) from other mount(s) > based first on whether security settings match (e.g. are both > Kerberos) and then on whether encryption is on/off and whether this is > a snapshot mount (smb3 previous versions feature). If neither is > mounted with a snaphsot and the encryption settings match then > we will use the same tree id to talk with the server as the other > mounts use. Interesting idea to allow mount to force a new > tree id. > > What was the NFS mount option you were talking about? > Looking at the nfs man page the only one that looked similar > was "nosharecache" I was remembering this from reading the nfs mount code: static int nfs_compare_super(struct super_block *sb, void *data) { ... if (!nfs_compare_super_address(old, server)) return 0; /* Note: NFS_MOUNT_UNSHARED == NFS4_MOUNT_UNSHARED */ if (old->flags & NFS_MOUNT_UNSHARED) return 0; ... } If a filesystem has NFS_MOUNT_UNSHARED set it does not serve as a candidate for new mount requests. Skimming the code it looks like nosharecache is what sets NFS_MOUNT_UNSHARED. Another interesting and common case is tmpfs which always creates a new filesystem instance whenever it is mounted. Eric