All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Omar Sandoval <osandov@osandov.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <jbacik@fb.com>,
	David Sterba <dsterba@suse.cz>, <linux-btrfs@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
Date: Wed, 8 Apr 2015 15:36:16 +0800	[thread overview]
Message-ID: <5524DA70.4060501@cn.fujitsu.com> (raw)
In-Reply-To: <20150408071703.GA24891@mew>



-------- Original Message  --------
Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval <osandov@osandov.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Date: 2015年04月08日 15:17

> On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote:
>>
>>
>> -------- Original Message  --------
>> Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
>> From: Omar Sandoval <osandov@osandov.com>
>> To: Chris Mason <clm@fb.com>, Josef Bacik <jbacik@fb.com>, David Sterba
>> <dsterba@suse.cz>, <linux-btrfs@vger.kernel.org>
>> Date: 2015年04月08日 13:34
>>
>>> Currently, mounting a subvolume with subvolid= takes a different code
>>> path than mounting with subvol=. This isn't really a big deal except for
>>> the fact that mounts done with subvolid= or the default subvolume don't
>>> have a dentry that's connected to the dentry tree like in the subvol=
>>> case. To unify the code paths, when given subvolid= or using the default
>>> subvolume ID, translate it into a subvolume name by walking
>>> ROOT_BACKREFs in the root tree and INODE_REFs in the filesystem trees.
>
> Hi, Qu,
>
>> Oh, this patch is what I have tried long long ago, and want to do the same
>> thing, to show subvolume mount for btrfs.
>
> Thanks for pointing that out, I didn't come across your post when I was
> looking around. I figured that someone must have thought of it first :)
>
>> But it came to me that, superblock->show_path() is a better method to do it.
>>
>> You can implement btrfs_show_path() to allow mountinfo to get the subvolume
>> name from subvolid, and don't change the mount routine much.
>
> Hm, I don't think that the changes to the mount code would be
> unwarranted. Having one code path makes it more obvious what's going on.
> Do you mind elaborating on why you preferred doing it in ->show_path()?
The story seems to be long.

At that time, I also tried to do the subvolid->path convert and it seems 
works.

But another problem, IIRC, btrfs losing its security label bug,
will be triggered more easy if we all go through the "subvol=" routine,
as that routine will use vfs_mount twice. The second time it will
definitely lost the security label.

Although the problem is later resolved by handling security label 
internally, but it drove me not touching the mount routine.


Also another problem is, "subvolid=" routine can also happen when the fs 
is already mounted, so there may be some operations ,like deleting files 
and dirs, interfere your subvolid->path search codes.
(During your while loop, there is a race windows between your 
release_path() and search_slot())
Resulting a mount failure even nothing goes wrong.

->show_path() method can't avoid above race problem, but the good thing 
is, even race happens, it won't disturb our mount.
Just a -EBUSY when showing /proc/self/mountinfo, not a mount failure.


Thanks,
Qu
>
> Thanks!
>
>> Thanks,
>> Qu
>

  reply	other threads:[~2015-04-08  7:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08  5:33 [PATCH 0/3] Btrfs: show subvolume name and ID in /proc/mounts Omar Sandoval
2015-04-08  5:34 ` [PATCH 1/3] Btrfs: lock superblock before remounting for rw subvol Omar Sandoval
2015-04-08  5:34 ` [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting Omar Sandoval
2015-04-08  6:06   ` Qu Wenruo
2015-04-08  7:17     ` Omar Sandoval
2015-04-08  7:36       ` Qu Wenruo [this message]
2015-04-09 16:10     ` David Sterba
2015-04-10  0:33       ` Qu Wenruo
2015-04-09 16:28   ` David Sterba
2015-04-09 19:03     ` Omar Sandoval
2015-04-08  5:34 ` [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts Omar Sandoval
2015-04-08  5:57   ` Qu Wenruo
2015-04-09 15:56   ` 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=5524DA70.4060501@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osandov@osandov.com \
    /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.