Re: subvolume info in /proc/mounts

Re: subvolume info in /proc/mounts

[Nikos Voutsinas]

> On Sat, Feb 04, 2012 at 08:40:51PM +0200, Nikos Voutsinas wrote:
>> There was a patch to include the subvolume mount option into
>> /proc/mounts.
>> Did that make it into the kernel;
>> If not, what is the formal way to find out which subvolume is mounted;
>  see /proc/self/mountinfo there is 'fs root' column, for bind mounts and
btrfs subvolumes is there '/<path>' (and '/' for normal mounts).
findmnt(8) uses the path in SOURCE column, for example
> /dev/sda1[/subvolume].

Thank you Karel, at least the list now has an answer on how to find the
mounted subvolume. For a moment I thought that no one had noticed this
part of the question.

In any production scenario, the first time you try to explore btrfs
subvolume capabilities it becomes obvious that this feature is missing and
it is weird how this has overlooked for such a long time.

Nikos

subvolume info in /proc/mounts

[Nikos Voutsinas]

Hi,

There was a patch to include the subvolume mount option into /proc/mounts.
Did that make it into the kernel;

If not, what is the formal way to find out which subvolume is mounted;

Cheers,
Nikos

Re: subvolume info in /proc/mounts

[David Sterba]

Hi,

On Sat, Feb 04, 2012 at 08:40:51PM +0200, Nikos Voutsinas wrote:
> There was a patch to include the subvolume mount option into /proc/mounts.
> Did that make it into the kernel;

I havent' seen such patch, do you have a link?

> If not, what is the formal way to find out which subvolume is mounted;

Not right now, see detailed answer to a similar question:
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15385

In short, possible but not implemented.


david

Re: subvolume info in /proc/mounts

[Nikos Voutsinas]

> Hi,
>
> On Sat, Feb 04, 2012 at 08:40:51PM +0200, Nikos Voutsinas wrote:
>> There was a patch to include the subvolume mount option into
>> /proc/mounts.
>> Did that make it into the kernel;
>
> I havent' seen such patch, do you have a link?
>
>> If not, what is the formal way to find out which subvolume is mounted;
>
> Not right now, see detailed answer to a similar question:
> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15385
>
> In short, possible but not implemented.
>

It's quite old, but what was this about;

http://thread.gmane.org/gmane.comp.file-systems.btrfs/4487

Assuming that pools with multiple subvolumes and/or snapshots is the way
of doing things in btrfs, the subvolume info is required for the every day
administration.

Re: subvolume info in /proc/mounts

[Fajar A. Nugraha]

On Sun, Feb 5, 2012 at 5:30 PM, Nikos Voutsinas <nvoutsin@noc.edunet.gr> wrote:
>>> If not, what is the formal way to find out which subvolume is mounted;
>>
>> Not right now, see detailed answer to a similar question:
>> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15385

> Assuming that pools with multiple subvolumes and/or snapshots is the way
> of doing things in btrfs, the subvolume info is required for the every day
> administration.

For simple administration, /etc/mtab (or the output of mount) as
mentioned in David's link should work.

-- 
Fajar

Re: subvolume info in /proc/mounts

[David Sterba]

On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote:
> It's quite old, but what was this about;
> 
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/4487

Thanks, the patch looks ok and works as expected.

Goffredo, do you want to resend it? (The lock around the mnt_root is not
necessary.) I think it's a -rc material, more people came to ask about
this on irc channel lately, we don't need to wait a full release cycle
to merge this fix.


david

Re: subvolume info in /proc/mounts

[Christoph Hellwig]

On Mon, Feb 06, 2012 at 12:53:21PM +0100, David Sterba wrote:
> On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote:
> > It's quite old, but what was this about;
> > 
> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/4487
> 
> Thanks, the patch looks ok and works as expected.
> 
> Goffredo, do you want to resend it? (The lock around the mnt_root is not
> necessary.) I think it's a -rc material, more people came to ask about
> this on irc channel lately, we don't need to wait a full release cycle
> to merge this fix.

No, it doesn't look good.  Please do not introduce anything touching
non-superblock fields in ->show_options, thanks.

Re: subvolume info in /proc/mounts

[Al Viro]

On Mon, Feb 06, 2012 at 07:18:24AM -0500, Christoph Hellwig wrote:
> On Mon, Feb 06, 2012 at 12:53:21PM +0100, David Sterba wrote:
> > On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote:
> > > It's quite old, but what was this about;
> > > 
> > > http://thread.gmane.org/gmane.comp.file-systems.btrfs/4487
> > 
> > Thanks, the patch looks ok and works as expected.
> > 
> > Goffredo, do you want to resend it? (The lock around the mnt_root is not
> > necessary.) I think it's a -rc material, more people came to ask about
> > this on irc channel lately, we don't need to wait a full release cycle
> > to merge this fix.
> 
> No, it doesn't look good.  Please do not introduce anything touching
> non-superblock fields in ->show_options, thanks.

Umm...  seq_dentry() on root dentry (which is what's getting passed to
->show_options() now) would be OK; this kind of playing with ->d_name
is not.

Re: subvolume info in /proc/mounts

[David Sterba]

On Mon, Feb 06, 2012 at 01:52:15PM +0000, Al Viro wrote:
> On Mon, Feb 06, 2012 at 07:18:24AM -0500, Christoph Hellwig wrote:
> > On Mon, Feb 06, 2012 at 12:53:21PM +0100, David Sterba wrote:
> > > On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote:
> > > > It's quite old, but what was this about;
> > > > 
> > > > http://thread.gmane.org/gmane.comp.file-systems.btrfs/4487
> > > 
> > > Thanks, the patch looks ok and works as expected.
> > > 
> > > Goffredo, do you want to resend it? (The lock around the mnt_root is not
> > > necessary.) I think it's a -rc material, more people came to ask about
> > > this on irc channel lately, we don't need to wait a full release cycle
> > > to merge this fix.
> > 
> > No, it doesn't look good.  Please do not introduce anything touching
> > non-superblock fields in ->show_options, thanks.

Sorry, I'll be more carefull with vfs patches.

> Umm...  seq_dentry() on root dentry (which is what's getting passed to
> ->show_options() now) would be OK; this kind of playing with ->d_name
> is not.

Thanks for the suggestion. This should do it, 


--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -766,6 +766,9 @@ static int btrfs_show_options(struct seq_file *seq, struct vfsmount *vfs)
                seq_puts(seq, ",inode_cache");
        if (btrfs_test_opt(root, SKIP_BALANCE))
                seq_puts(seq, ",skip_balance");
+       seq_puts(seq, ",subvol=");
+       seq_dentry(seq, vfs->mnt_root, " \t\n\\");
+
        return 0;
 }

( plus EXPORT_SYMBOL(seq_dentry) )

The 3rd argument (chars to be escaped in the path), is same as passed to other
seq_* funcs, though I'm not sure if we don't want to escape ',' as well, since
it may confuse option parsers out there. If the subvol= is kept as the last
one, then actual path is from '=' up to the first unescaped ' '.

If touching dentry name is forbidden, then we could entirely skip checking
whether it's '/', and always show subvol path. I don't see a problem from
user's/administrator's POV (and I'm not going to invent another way to check
for '/' by looking to other internal vfs items).

Full patch:

From: David Sterba <dsterba@suse.cz>

Although it's not necessarily needed to show the mount option for the
toplevel subvolume, we cannot touch dentry name or other internal items
to check for it.

Signed-off-by: David Sterba <dsterba@suse.cz>
---
 fs/btrfs/super.c |    6 ++++++
 fs/seq_file.c    |    1 +
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 61717a4..dda5d6e 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -766,6 +766,12 @@ static int btrfs_show_options(struct seq_file *seq, struct vfsmount *vfs)
 		seq_puts(seq, ",inode_cache");
 	if (btrfs_test_opt(root, SKIP_BALANCE))
 		seq_puts(seq, ",skip_balance");
+	/*
+	 * Keep this one at the end
+	 */
+	seq_puts(seq, ",subvol=");
+	seq_dentry(seq, vfs->mnt_root, " \t\n\\");
+
 	return 0;
 }
 
diff --git a/fs/seq_file.c b/fs/seq_file.c
index dba43c3..ccbcc56 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -498,6 +498,7 @@ int seq_dentry(struct seq_file *m, struct dentry *dentry, char *esc)
 
 	return res;
 }
+EXPORT_SYMBOL(seq_dentry);
 
 int seq_bitmap(struct seq_file *m, const unsigned long *bits,
 				   unsigned int nr_bits)
-- 
1.7.8

Re: subvolume info in /proc/mounts

[David Sterba]

On Thu, Feb 09, 2012 at 02:44:03PM +0100, David Sterba wrote:
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -766,6 +766,9 @@ static int btrfs_show_options(struct seq_file *seq, struct vfsmount *vfs)
>                 seq_puts(seq, ",inode_cache");
>         if (btrfs_test_opt(root, SKIP_BALANCE))
>                 seq_puts(seq, ",skip_balance");
> +       seq_puts(seq, ",subvol=");
> +       seq_dentry(seq, vfs->mnt_root, " \t\n\\");
> +
>         return 0;
>  }

This is still not enough, if there's a (non-toplevel) default subvolume
set at the time of mount, it will not be printed within the path.

The path in mount option "subvol=PATH" is resolved relative to the
toplevel subvolume regardless of the default subvol, and show_options
shold follow the same logic to be fully symmetric.

I don't think path resolving is allowed from inside show_options. So we
could:

 * resolve the path inside btrfs_mount (we're looking up the default
   root item anyway)
 * save the full path inside the fs_tree root (the fs_info structure is
   shared by all moutned subvols from the same filesystem and cannot be
   used for this purpose, and the default subvol could change anytime)
 * print the fs_root->default_root_path before the seq_dentry


david

Re: subvolume info in /proc/mounts

[Goffredo Baroncelli]

Hi Christoph

On Monday, 06 February, 2012 13:18:24 Christoph Hellwig wrote:
> On Mon, Feb 06, 2012 at 12:53:21PM +0100, David Sterba wrote:
> > On Sun, Feb 05, 2012 at 12:30:42PM +0200, Nikos Voutsinas wrote:
> > > It's quite old, but what was this about;
> > > 
> > > http://thread.gmane.org/gmane.comp.file-systems.btrfs/4487
> > 
> > Thanks, the patch looks ok and works as expected.
> > 
> > Goffredo, do you want to resend it? (The lock around the mnt_root is not
> > necessary.) I think it's a -rc material, more people came to ask about
> > this on irc channel lately, we don't need to wait a full release cycle
> > to merge this fix.
> 
> No, it doesn't look good.  Please do not introduce anything touching
> non-superblock fields in ->show_options, thanks.

could you elaborate your sentence ? What is the problem ? The subvolume name 
could be a very precious information.



> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: subvolume info in /proc/mounts

[Karel Zak]

On Sat, Feb 04, 2012 at 08:40:51PM +0200, Nikos Voutsinas wrote:
> There was a patch to include the subvolume mount option into /proc/mounts.
> Did that make it into the kernel;
> 
> If not, what is the formal way to find out which subvolume is mounted;

 see /proc/self/mountinfo there is 'fs root' column, for bind mounts
 and btrfs subvolumes is there '/<path>' (and '/' for normal mounts).

 findmnt(8) uses the path in SOURCE column, for example /dev/sda1[/subvolume].

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com