All of lore.kernel.org
 help / color / mirror / Atom feed
From: Calvin Walton <calvin.walton@gmail.com>
To: C Anthony Risinger <anthony@extof.me>
Cc: linux-btrfs@vger.kernel.org
Subject: [RFC-PATCH] Re: mounting arbitrary directories
Date: Sat, 27 Nov 2010 23:22:13 -0500	[thread overview]
Message-ID: <1290918133.14274.20.camel@nayuki> (raw)
In-Reply-To: <AANLkTi=7LY6y3BvGgkyYBTLwu=SYJjZZhL8kHusCn_vs@mail.gmail.com>

On Sat, 2010-11-27 at 21:19 -0600, C Anthony Risinger wrote:
> i have read just recently and in the past that btrfs supports COW for
> _any_ file/directory (this is reflinks, yes?), and today i
> accidentally noticed that i can mount a directory as well (if it's in
> the top level volume at least).
> 
> eg. if i have a "regular" directory (not a subvolume) in the top-level:
> 
> /__boot
> 
> i can mount it with:
> 
> mount -o subvol=__boot /dev/sda /mnt

The 'subvol' option actually works using the same mechanism as a bind
mount. The fact that it works using a directory is purely a coincidence
- I would not expect it to be officially supported, and you shouldn't
rely on it.

> i am working on an update to my initramfs hook that will utilize
> extlinux, and this property to provide seamless kernel level system
> rollbacks, and i want to make sure it's safe to do this.

To handle system rollbacks, you really should be using subvolumes and
snapshots, not regular directories.

> also, is there a way to target an arbitrary directory?  does "subvol"
> support paths yet, or maybe via "subvolid" somehow?  essentially i

I don't think that it would be very hard to make subvol= support a path
instead of only one level deep. Actually, I think I could make a patch
for that myself... I've included it here. Mildly tested, but I'm not
really a kernel programmer and might have missed something -
particularly with regards to the locking.

> just want to mount a directory inside a snapshot at /boot, so when
> users upgrade there kernels, the images are visible to extlinux (which
> cannot yet peek inside or use subvolumes, so it has to be a regular
> directory in the top-level volume)

Ah, this is the first I've heard that extlinux doesn't support reading
files in subvolumes. That's an unfortunate limitation :/

------------------------8<----------8<---------------------

From: Calvin Walton <calvin.walton@gmail.com>
Date: Sat, 27 Nov 2010 23:17:55 -0500
Subject: [PATCH] Btrfs: Allow mounting sub-sub(-sub...)-volumes using subvol=a/b/c

Currently you can only mount subvolumes which are direct children of the
'default' root. I.e. with

	ID 258 top level 5 path a
	ID 259 top level 5 path a/b

you could mount with "-o subvol=a" but not "-o subvol=a/b"

This patch fixes that by recursively following the path to the subvolume.

Signed-off-by: Calvin Walton <calvin.walton@gmail.com>
---
 fs/btrfs/super.c |   41 +++++++++++++++++++++++------------------
 1 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 8299a25..5e78c86 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -646,26 +646,31 @@ static struct dentry *btrfs_mount(struct file_system_type *fs_type, int flags,
 	/* if they gave us a subvolume name bind mount into that */
 	if (strcmp(subvol_name, ".")) {
 		struct dentry *new_root;
-		mutex_lock(&root->d_inode->i_mutex);
-		new_root = lookup_one_len(subvol_name, root,
-				      strlen(subvol_name));
-		mutex_unlock(&root->d_inode->i_mutex);
-
-		if (IS_ERR(new_root)) {
-			deactivate_locked_super(s);
-			error = PTR_ERR(new_root);
-			dput(root);
-			goto error_free_subvol_name;
-		}
-		if (!new_root->d_inode) {
+		char *subvol_name_next = subvol_name;
+		char *subvol_name_part;
+
+		while ((subvol_name_part = strsep(&subvol_name_next, "/"))) {
+			mutex_lock(&root->d_inode->i_mutex);
+			new_root = lookup_one_len(subvol_name, root,
+						strlen(subvol_name));
+			mutex_unlock(&root->d_inode->i_mutex);
+
+			if (IS_ERR(new_root)) {
+				deactivate_locked_super(s);
+				error = PTR_ERR(new_root);
+				dput(root);
+				goto error_free_subvol_name;
+			}
+			if (!new_root->d_inode) {
+				dput(root);
+				dput(new_root);
+				deactivate_locked_super(s);
+				error = -ENXIO;
+				goto error_free_subvol_name;
+			}
 			dput(root);
-			dput(new_root);
-			deactivate_locked_super(s);
-			error = -ENXIO;
-			goto error_free_subvol_name;
+			root = new_root;
 		}
-		dput(root);
-		root = new_root;
 	}
 
 	kfree(subvol_name);
-- 
1.7.3.2

-- 
Calvin Walton <calvin.walton@gmail.com>


  reply	other threads:[~2010-11-28  4:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28  3:19 mounting arbitrary directories C Anthony Risinger
2010-11-28  4:22 ` Calvin Walton [this message]
2010-11-28  9:41   ` [RFC-PATCH] " C Anthony Risinger
2010-11-28 10:07   ` C Anthony Risinger
2010-11-29 17:42     ` C Anthony Risinger
2010-12-03  9:41       ` C Anthony Risinger

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=1290918133.14274.20.camel@nayuki \
    --to=calvin.walton@gmail.com \
    --cc=anthony@extof.me \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.