All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: <lists@xunil.at>, <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs and mount in gentoo linux
Date: Wed, 9 Jul 2014 09:57:17 +0800	[thread overview]
Message-ID: <53BCA17D.9060301@cn.fujitsu.com> (raw)
In-Reply-To: <53BC5A1A.7020403@xunil.at>


-------- Original Message --------
Subject: Re: btrfs and mount in gentoo linux
From: Stefan G. Weichinger <lists@xunil.at>
To: linux-btrfs@vger.kernel.org
Date: 2014年07月09日 04:52
> Am 08.07.2014 22:19, schrieb Holger Hoffstätte:
>> On Tue, 08 Jul 2014 21:07:30 +0200, Stefan G. Weichinger wrote:
>>
>>> I am a happy btrfs-user with gentoo linux for some time now and noticed
>>> that the command "mount" does not show me which subvolid is mounted where.
>> Interestingly I just found that this came up in Fedora some time ago:
>> https://bugzilla.redhat.com/show_bug.cgi?id=743118
>>
>> findmnt seems to do the trick, so the underlying functionality in
>> libmnt seems to work. Maybe Debian's mount does something differently?
> findmnt does not fully show the subvolids or names:
>
>
> # findmnt  | grep btrfs
> /                                /dev/sda3[/rootfs]    btrfs
> rw,noatime,compress=lzo,ssd,space_cache
> ├─/mnt/uncow                     /dev/sda3             btrfs
> rw,noatime,compress=lzo,ssd,space_cache
> └─/home/sgw                      /dev/mapper/_dev_sda4 btrfs
> rw,noatime,compress=lzo,ssd,space_cache
>
> The "[/rootfs]" is something in the right direction ...
The bug is that, if you don't use 'subvol=' mount option but use default 
subvolume or 'subvolid=' mount option,
findmnt will not give the output.

Since 'subvol=' mount option differs from default subvolume mount or 
'subvolid=' mount option in calling behavior,
'subvol=' uses mount_subtree() vfs call, which records subtree mount info.
On the other hand, default subvolume mount or 'subvolid=' mount does not 
go through the vfs subtree mount
but use btrfs's implement, which does not report vfs submount.

I'll try to investigate further and find whether we can fix it to show 
more info.

Thanks,
Qu
>
> S
> --
> 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


  reply	other threads:[~2014-07-09  1:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-08 19:07 btrfs and mount in gentoo linux Stefan G. Weichinger
2014-07-08 20:19 ` Holger Hoffstätte
2014-07-08 20:52   ` Stefan G. Weichinger
2014-07-09  1:57     ` Qu Wenruo [this message]
2014-07-09  9:15       ` Stefan G. Weichinger
2014-07-08 20:20 ` Chris Murphy
2014-07-08 20:50   ` Stefan G. Weichinger
2014-07-08 21:27     ` Chris Murphy

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=53BCA17D.9060301@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@xunil.at \
    /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.