Thanks for the comment.
-------- Original Message --------
Subject: Re: [PATCH] btrfs: Add show_path function for btrfs_super_ops.
From: David Sterba <[email protected]>
To: Qu Wenruo <[email protected]>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
