All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: <dsterba@suse.cz>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs: Add show_path function for btrfs_super_ops.
Date: Thu, 31 Jul 2014 11:50:11 +0800	[thread overview]
Message-ID: <53D9BCF3.80001@cn.fujitsu.com> (raw)
In-Reply-To: <53D1A78E.8020802@cn.fujitsu.com>

Hi David,

No mean to disturb you, but it has been serveral days since last comment.

If you have any comment about the new patch, since due to my lack of 
explain the patch seems not
reviewed, I am very glad to hear.

If any other ideas occur to you, like the pro and cons about old mount 
trick vs show_path() implement,
it would be also quite nice.

Thanks,
Qu


-------- Original Message --------
Subject: Re: [PATCH] btrfs: Add show_path function for btrfs_super_ops.
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Date: 2014年07月25日 08:40
> Thanks for the comment.
>
> -------- Original Message --------
> Subject: Re: [PATCH] btrfs: Add show_path function for btrfs_super_ops.
> From: David Sterba <dsterba@suse.cz>
> To: Qu Wenruo <quwenruo@cn.fujitsu.com>
> Date: 2014年07月24日 21:09
>> On Mon, Jul 21, 2014 at 05:02:29PM +0800, Qu Wenruo wrote:
>>> show_path() function in struct super_operations is used to output
>>> subtree mount info for mountinfo.
>>> Without the implement of show_path() function, user can not found where
>>> each subvolume is mounted if using 'subvolid=' mount option.
>>> (When mounted with 'subvol=' mount option, vfs is aware of subtree 
>>> mount
>>> and can to the path resolve by vfs itself)
>> Your previous patches unify both to call mount_subtree, then the default
>> vfs implementation of show_path will do the right thing, ie
>> seq_dentry(...), and the path will be resolved for free.
>>
>> Means this patch is not needed, so I'll skip commenting it.
>
> I'm sorry that I forgot to mention this patch is going to replace the 
> previous patch(use mount_subtree method).
>
> Since vfs provide the show_path() function to do the fs specific 
> subtree showing things,
> I would like to use it other than previous mount_subtree() trick.
>
> Also. as mentioned by Chandan Rajendra, previous subtree patch can't 
> handle subvolume behind normal directory.
> This show_path() patch is somewhat v2 version of previous patch.
>>
>>> With this patch, end users will be able to use findmnt(8) or other
>>> programs reading mountinfo to find which btrfs subvolume is mounted.
>>>
>>> Though we use fs_info->subvol_sem to protect show_path() from subvolume
>>> destroying/creating, if user renames/moves the parent non-subvolume
>>> dir of a subvolume, it is still possible that concurrency may happen 
>>> and
>>> cause btrfs_search_slot() fails to find the desired key.
>>> In that case, we just return -EBUSY and info user to try again since
>>> extra locking like locking the whole subvolume tree is too expensive 
>>> for
>>> such usage.
>> And the subvolume renames will be handled as well.


  reply	other threads:[~2014-07-31  3:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21  9:02 [PATCH] btrfs: Add show_path function for btrfs_super_ops Qu Wenruo
2014-07-24 13:09 ` David Sterba
2014-07-25  0:40   ` Qu Wenruo
2014-07-31  3:50     ` Qu Wenruo [this message]
2014-10-27  4:10       ` Qu Wenruo
2015-04-08  5:59 ` Qu Wenruo

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=53D9BCF3.80001@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.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 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.