Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1636464

Re: [RFC][PATCH 0/9] VFS: Introduce mount context

From David Howells <dhowells@redhat.com>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 0/9] VFS: Introduce mount context
Date 2017-05-05 17:50 +0200
Message-ID <tDNEt-3DR-9@gated-at.bofh.it> (permalink)
References <tDMyJ-2YY-7@gated-at.bofh.it> <tD50J-7GP-3@gated-at.bofh.it> <tDMyJ-2YY-7@gated-at.bofh.it>
Organization Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903

Show all headers | View raw

Miklos Szeredi <mszeredi@redhat.com> wrote:

> I'd argue with some design decisions here.  One of the motivations for
> doing the mount API overhaul is to create clear distinction between
> separate functions like:
> 
>  - creating filesystem instance (aka superblock)
> 
>  - attaching filesystem instance into mount tree
> 
>  - reconfiguring superblock
> 
>  - changing mount properties

I definitely agree that keeping a separation between vfsmount manipulation
(add, bind, move, ...) and superblock manipulation (create, remount) is a good
idea.

However, creating new superblocks and remounting superblocks have a lot in
common, including the option parsing.  Note also that existing code is
somewhat lazy about rejecting parameters that can't be changed with a remount
and will ignore some attempted changes.  We have to retain this behaviour, at
least for the normal mount() system call.

Note that one of the main reasons I'm working on this is namespace
propagation, particularly with respect to automounts.

> This patchset achieves this partly, but the separation is far from
> crisp clear...  First of all why is fsopen() creating a "mount
> context"?  It's suppsed to create a "superblock creation context".

I've no particular objection to renaming struct mount_context to something
else, but it also needs to handle remount because of the commonality.

Further, once you've created a superblock, what are you going to do with it
other than mount it?  I suppose you could statfs it and we could add other
superblock manipulation functions, but this is normally done by opening the
device directly (at least for bdev-based superblocks).

> And indeed, there are mount flags and root path in there, which are
> definitely not necessary for creating a super block.

Erm, that's not strictly true.

Some filesystems (eg. nfs, ocfs2, lustre) want to know about certain MNT_xxx
flags, such as MNT_NOATIME and MNT_READONLY.

Further, the root path might be necessary for the mount - see NFS for example.
What I was thinking of, say for NFS, is splitting the source name up front,
so:

	my.nfs.org:/my/home/dir

into:

	mc->device = "my.nfs.org";
	mc->root_path = "/my/home/dir";

and then having the VFS handle the root walk rather than doing it inside NFS.
This facility could then become available to other filesystems potentially.

However, with the case on NFS, you may need to hand the root path off to a
mount server.

> Is there a good reason why these mount specific properties leaked into
> the object created by fsopen()?

Answered above.  I'm okay with removing remove root_path from the context for
the moment.  It's something that can be revisited later.

We also might need to remove usage of MNT_xxx flags from filesystems.

> Also I'd expect all context ops to be fully generic first.  I.e. no
> filesystem code needs to be touched to make the new interface work.
> The context would just build the option string and when everything is
> ready (probably need a "commit" command) then it would go off and call
> mount_fs() to create the superblock and attach it to the context.

That should be easy enough to add as a fallback.

> Then, when that works, we could add context ops, so the filesystem can
> do various things along the way, which is the other reason we want
> this.  And in the end it would allow gradual migration to a new
> superblock creation api and phasing out the old one.

I'm not sure the context ops are so easily to add gradually.

> But that shouldn't be observable on either the old or the new userspace
> interfaces.

Almost a fair point - but it can be observed by pushing in more than a page's
worth of options.  What I have now for NFS will still work with
fsopen()/write()/fsmount() whereas mount() won't.

David

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC][PATCH 0/9] VFS: Introduce mount context David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
  [PATCH 1/9] Provide a function to create a NUL-terminated string  from unterminated data David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
    Re: [PATCH 1/9] Provide a function to create a NUL-terminated  string from unterminated data Jeff Layton <jlayton@poochiereds.net> - 2017-05-03 19:00 +0200
    Re: [PATCH 1/9] Provide a function to create a NUL-terminated string from unterminated data Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2017-05-03 21:30 +0200
      Re: [PATCH 1/9] Provide a function to create a NUL-terminated string from unterminated data David Howells <dhowells@redhat.com> - 2017-05-03 22:20 +0200
  [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
    Re: [PATCH 4/9] Implement fsopen() to prepare for a mount Jeff Layton <jlayton@poochiereds.net> - 2017-05-03 20:40 +0200
      Re: [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-03 20:50 +0200
    Re: [PATCH 4/9] Implement fsopen() to prepare for a mount Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2017-05-03 22:50 +0200
      Re: [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-04 15:00 +0200
      Re: [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-04 15:00 +0200
    Re: [PATCH 4/9] Implement fsopen() to prepare for a mount Karel Zak <kzak@redhat.com> - 2017-05-04 12:50 +0200
      Re: [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-04 15:10 +0200
        Re: [PATCH 4/9] Implement fsopen() to prepare for a mount Karel Zak <kzak@redhat.com> - 2017-05-04 15:40 +0200
          Re: [PATCH 4/9] Implement fsopen() to prepare for a mount Jeff Layton <jlayton@redhat.com> - 2017-05-09 20:50 +0200
    Re: [PATCH 4/9] Implement fsopen() to prepare for a mount Miklos Szeredi <mszeredi@redhat.com> - 2017-05-08 17:20 +0200
      Re: [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells <dhowells@redhat.com> - 2017-05-09 01:20 +0200
  [PATCH 5/9] Implement fsmount() to effect a pre-configured mount David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
  [PATCH 2/9] Clean up whitespace in fs/namespace.c David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
  [PATCH 8/9] proc: Support the mount context in procfs David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
  [PATCH 7/9] procfs: Move proc_fill_super() to fs/proc/root.c David Howells <dhowells@redhat.com> - 2017-05-03 18:10 +0200
  Re: [RFC][PATCH 0/9] VFS: Introduce mount context Jeff Layton <jlayton@poochiereds.net> - 2017-05-03 18:50 +0200
    Re: [RFC][PATCH 0/9] VFS: Introduce mount context David Howells <dhowells@redhat.com> - 2017-05-03 19:00 +0200
      Re: [RFC][PATCH 0/9] VFS: Introduce mount context Jeff Layton <jlayton@poochiereds.net> - 2017-05-03 19:30 +0200
  Re: [PATCH 3/9] VFS: Introduce a mount context Joe Perches <joe@perches.com> - 2017-05-03 20:30 +0200
    Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-03 20:40 +0200
      Re: [PATCH 3/9] VFS: Introduce a mount context Joe Perches <joe@perches.com> - 2017-05-03 20:50 +0200
        Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-03 22:20 +0200
    Re: [PATCH 3/9] VFS: Introduce a mount context Matthew Wilcox <willy@infradead.org> - 2017-05-03 22:40 +0200
      Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-03 23:20 +0200
      Re: [PATCH 3/9] VFS: Introduce a mount context Joe Perches <joe@perches.com> - 2017-05-03 23:40 +0200
        Re: [PATCH 3/9] VFS: Introduce a mount context Julia Lawall <julia.lawall@lip6.fr> - 2017-05-04 08:30 +0200
    Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-04 11:30 +0200
      Re: [PATCH 3/9] VFS: Introduce a mount context Joe Perches <joe@perches.com> - 2017-05-04 16:40 +0200
  Re: [PATCH 3/9] VFS: Introduce a mount context Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2017-05-03 23:50 +0200
    Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-04 12:30 +0200
  Re: [RFC][PATCH 0/9] VFS: Introduce mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-05 16:40 +0200
    Re: [RFC][PATCH 0/9] VFS: Introduce mount context David Howells <dhowells@redhat.com> - 2017-05-05 17:50 +0200
      Re: [RFC][PATCH 0/9] VFS: Introduce mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-08 10:30 +0200
      Re: [RFC][PATCH 0/9] VFS: Introduce mount context David Howells <dhowells@redhat.com> - 2017-05-08 10:40 +0200
        Re: [RFC][PATCH 0/9] VFS: Introduce mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-08 10:50 +0200
  Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-08 17:10 +0200
    Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-09 01:00 +0200
      Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-09 10:10 +0200
        Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-09 11:40 +0200
          Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-09 13:10 +0200
        Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-09 11:50 +0200
          Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-09 14:10 +0200
            Re: [PATCH 3/9] VFS: Introduce a mount context Jeff Layton <jlayton@redhat.com> - 2017-05-09 21:00 +0200
              Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-10 09:30 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-10 10:10 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context Jeff Layton <jlayton@redhat.com> - 2017-05-10 15:30 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-10 15:40 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context Jeff Layton <jlayton@redhat.com> - 2017-05-10 15:40 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-10 15:40 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-10 15:40 +0200
                Re: [PATCH 3/9] VFS: Introduce a mount context Jeff Layton <jlayton@redhat.com> - 2017-05-10 15:50 +0200
        Re: [PATCH 3/9] VFS: Introduce a mount context David Howells <dhowells@redhat.com> - 2017-05-09 12:00 +0200
          Re: [PATCH 3/9] VFS: Introduce a mount context Miklos Szeredi <mszeredi@redhat.com> - 2017-05-09 14:40 +0200
        Re: [PATCH 3/9] VFS: Introduce a mount context Karel Zak <kzak@redhat.com> - 2017-05-10 14:50 +0200
  Re: [RFC][PATCH 0/9] VFS: Introduce mount context Djalal Harouni <tixxdz@gmail.com> - 2017-05-08 19:10 +0200

csiph-web