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 -- 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
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 -- 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
> 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. -- 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
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 -- 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
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 -- 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
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/4487Thanks, 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 -- 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
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. -- 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
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. -- 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
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-- 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
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 -- 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
> 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 andbtrfs 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 -- 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
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 -- 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