linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Misono, Tomohiro" <misono.tomohiro@jp.fujitsu.com>
To: <linux-btrfs@vger.kernel.org>
Cc: <dsterba@suse.cz>, <anand.jain@oracle.com>
Subject: [PATCH v3 0/4] btrfs: cleanup mount path
Date: Mon, 25 Sep 2017 16:26:30 +0900	[thread overview]
Message-ID: <4786f7cc-adc7-1b99-5abf-d068acee56c2@jp.fujitsu.com> (raw)

Summary:
Cleanup mount path by avoiding calling btrfs_mount() twice.
No functional change. See below for longer explanation.

Changelog:
v3:
  Reorganized patches again into four and added comments to the source.
  Each patch can be applied and compiled while maintaining functionality.
  The first one is the preparation and the second one is the main part.
  The last two are small cleanups.

v2:
  Split the patch into three parts.

Tomohiro Misono (4):
  btrfs: add mount_root() and new file_system_type
  btrfs: cleanup btrfs_mount() using mount_root()
  btrfs: split parse_early_options() in two
  btrfs: remove unused setup_root_args()

 fs/btrfs/super.c | 252 ++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 149 insertions(+), 103 deletions(-)

====================
Background Explanation:
btrfs uses mount_subtree() to mount a subvolume directly.  This function
needs a vfsmount* of device's root (/), which is a return value of
vfs_kern_mount() (therefore root has to be mounted internally anyway).

Current approach of getting root's vfsmount* in mount time is a bit tricky:
0. VFS layer calls vfs_kern_mount() with registered file_system_type
   (for btrfs, btrfs_fs_type). btrfs_mount() is called on the way.
1. btrfs_parse_early_options() parses "subvolid=" mount option and set the
   value to subvol_objectid. Otherwise, subvol_objectid has the initial
   value of 0
2. check subvol_objectid is 5 or not. This time id is not 5, and
   btrfs_mount() returns by calling mount_subvol()
3. In mount_subvol(), original mount options are modified to contain
   "subvolid=0" in setup_root_args(). Then, vfs_kern_mount() is called with
   btrfs_fs_type and new options
4. btrfs_mount() is called again
5. btrfs_parse_early_options() parses "subvolid=0" and set 5 (instead of 0)
   to subvol_objectid
6. check subvol_objectid is 5 or not. This time id is 5 and mount_subvol()
   is not called. btrfs_mount() finishes mounting a root
7. (in mount_subvol()) with using a return vale of vfs_kern_mount(), it
   calls mount_subtree()
8 return subvolume's dentry

As illustrated above, calling btrfs_mount() twice complicates the problem.
We can use another file_system_type (which has different callback
function to mount root) for arguments of our vfs_kern_mount() call to 
avoid this.

In this approach: 
1. parse subvol id related options for later use in mount_subvol()
2. mount device's root by calling vfs_kern_mount() with
   different file_system_type
3. return by calling mount_subvol()

I think this approach is the same as nfsv4, which is the only other
filesystem using mount_subtree() currently, and easy to understand.

Most of the change is done by just reorganizing the original code of
btrfs_mount()/mount_subvol() into btrfs_mount()/mount_subvol()/mount_root()

btrfs_parse_early_options() is split into two parts to avoid "device="
option will be handled twice (though it cause no harm). setup_root_args()
is deleted as not needed anymore.

-- 
2.9.5


             reply	other threads:[~2017-09-25  7:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25  7:26 Misono, Tomohiro [this message]
2017-09-25  7:27 ` [PATCH 1/4] btrfs: add mount_root() and new file_system_type Misono, Tomohiro
2017-12-12 20:07   ` David Sterba
2017-09-25  7:28 ` [PATCH 2/4] btrfs: cleanup btrfs_mount() using mount_root() Misono, Tomohiro
2017-09-25  7:28 ` [PATCH 3/4] btrfs: split parse_early_options() in two Misono, Tomohiro
2017-12-12 20:10   ` David Sterba
2017-09-25  7:29 ` [PATCH 4/4] btrfs: remove unused setup_root_args() Misono, Tomohiro
2017-10-16 15:15 ` [PATCH v3 0/4] btrfs: cleanup mount path David Sterba
2017-12-12 20:12   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4786f7cc-adc7-1b99-5abf-d068acee56c2@jp.fujitsu.com \
    --to=misono.tomohiro@jp.fujitsu.com \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).