GNU bug report logs - #17676
btrfs subvolumes and bind-mounts make df report incorrect and/or extra results

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: coreutils; Reported by: David Schleimer <dschleimer@HIDDEN>; dated Tue, 3 Jun 2014 15:35:02 UTC; Maintainer for coreutils is bug-coreutils@HIDDEN.

Message received at 17676 <at> debbugs.gnu.org:


Received: (at 17676) by debbugs.gnu.org; 4 Jun 2014 01:52:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 03 21:52:03 2014
Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Ws0N0-0003ue-Ah
	for submit <at> debbugs.gnu.org; Tue, 03 Jun 2014 21:52:03 -0400
Received: from mail2.vodafone.ie ([213.233.128.44]:54943)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <P@HIDDEN>) id 1Ws0Mx-0003uD-12
 for 17676 <at> debbugs.gnu.org; Tue, 03 Jun 2014 21:52:00 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4BABp7jlNtTCE0/2dsb2JhbAANTINZVcJ3AYEggxkBAQEEMgFGEAsNAQoJFAIPCQMCAQIBRQYNAQcBAYhDq0GmTBeNew5JB4RABJtIhViOFYFBa4EBASM
Received: from unknown (HELO [192.168.1.79]) ([109.76.33.52])
 by mail2.vodafone.ie with ESMTP; 04 Jun 2014 02:51:43 +0100
Message-ID: <538E7BAF.1090707@HIDDEN>
Date: Wed, 04 Jun 2014 02:51:43 +0100
From: =?ISO-8859-1?Q?P=E1draig_Brady?= <P@HIDDEN>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: David Schleimer <dschleimer@HIDDEN>
Subject: Re: bug#17676: btrfs subvolumes and bind-mounts make df report
 incorrect and/or extra results
References: <B647040404E33F408448F7343768AE7A76F70BC5@HIDDEN>
In-Reply-To: <B647040404E33F408448F7343768AE7A76F70BC5@HIDDEN>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 17676
Cc: 17676 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

On 06/03/2014 04:21 PM, David Schleimer wrote:
> When you have btrfs mount where there is a both a subvolume of that mount, and the source of a bind-mount under that mount, df will report confusing results.  It will show results for the bind-mount instead of the main btrfs mount when you pass the subvoulme on the command line.  It may (depending on the system) show both the bind-mount and main mount in bare df results.
> 
> I've attached a script with the minimal repro instructions.  It needs to be run as root since it (temporarily) mounts filesystems under your tmpdir.
> 
> I tested on two machines:
> Fedora 20 running kernel 3.14.4-200.fc20.x86_64, against both the system df 8.21 and df 8.22 built from source.
> 
> Centos 6.4 running a 3.10.39 variant, with significant backports, notably including most btrfs changes from mainline.  Testing against the system df 8.4, and df 8.22 again built from source.
> 
> On the fedora machine, /etc/mtab is a symlink to /proc/self/mounts.  We see output that refers to the correct block device in all cases.  However, we see a report for the bind-mount destination instead of the main btrfs mount when asking specifically for the subvolume path, and see results for both the main btrfs filesystem and the bind-mount when we run a bare df.
> 
> Transcript of Fedora output:
> 
> [root@caitsidhe dschleimer]# ./repro_instructions.sh
> 1024+0 records in
> 1024+0 records out
> 10485760 bytes (10 MB) copied, 0.00963354 s, 1.1 GB/s SMALL VOLUME: forcing mixed metadata/data groups
> 
> WARNING! - Btrfs v3.12 IS EXPERIMENTAL
> WARNING! - see http://btrfs.wiki.kernel.org before using
> 
> Turning ON incompat feature 'mixed-bg': mixed data and metadata block groups Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 Created a data/metadata chunk of size 1048576 fs created label (null) on block
>         nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MiB Btrfs v3.12 Create subvolume 'filesystem/subvolume'
> 
> 
> 
> Begin unexpected output
> Filesystem     1K-blocks  Used Available Use% Mounted on
> /dev/loop0         10240    36      6112   1% /tmp/tmp.biUryZcwD9/binddest
> Expected report for the main btrfs mount, not the bind-mount
> /dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp.biUryZcwD9/filesystem
> /dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp.biUryZcwD9/binddest
> Expected only one btrfs filesystem
> /home/dschleimer
> [root@caitsidhe dschleimer]# PATH=/home/dschleimer/Downloads/coreutils-8.22/src/:$PATH ./repro_instructions.sh
> 1024+0 records in
> 1024+0 records out
> 10485760 bytes (10 MB) copied, 0.012752 s, 822 MB/s SMALL VOLUME: forcing mixed metadata/data groups
> 
> WARNING! - Btrfs v3.12 IS EXPERIMENTAL
> WARNING! - see http://btrfs.wiki.kernel.org before using
> 
> Turning ON incompat feature 'mixed-bg': mixed data and metadata block groups Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 Created a data/metadata chunk of size 1048576 fs created label (null) on block
>         nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MiB Btrfs v3.12 Create subvolume 'filesystem/subvolume'
> 
> 
> 
> Begin unexpected output
> Filesystem     1K-blocks  Used Available Use% Mounted on
> /dev/loop0         10240    36      6112   1% /tmp/tmp.TEBR2D9Vta/binddest
> Expected report for the main btrfs mount, not the bind-mount
> /dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp.TEBR2D9Vta/filesystem
> /dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp.TEBR2D9Vta/binddest
> Expected only one btrfs filesystem
> /home/dschleimer
> 
> On Centos, /etc/mtab is a plain file.  When asking specifically for the subvolume, we see a report for the bind-mount dest which lists the bind-mount source as the filesystem.  When we run a bare df, we see only one record with the file backing the loopback device as the filesystem, but the bind-mount as the mount-point.
> 
> Centos transcript:
> 
> [08:03:09 Tue Jun 03 2014] root@HIDDEN /home/dschleimer dschleimer  282 $ ./repro_instructions.sh
> 1024+0 records in
> 1024+0 records out
> 10485760 bytes (10 MB) copied, 0.0101568 s, 1.0 GB/s
> 
> WARNING! - Btrfs v0.20-rc1-358-g194aa4a IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using
> 
> SMALL VOLUME: forcing mixed metadata/data groups Created a data/metadata chunk of size 1048576 fs created label (null) on block
>         nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MB Btrfs v0.20-rc1-358-g194aa4a Create subvolume 'filesystem/subvolume'
> 
> 
> 
> Begin unexpected output
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /tmp/tmp.V4FNWcBXke/filesystem/subvolume/bindsource
>                          10240        36      6112   1% /tmp/tmp.V4FNWcBXke/binddest
> Expected report for the main btrfs mount, not the bind-mount
> df: `/mnt/gvfs': Function not implemented /tmp/tmp.V4FNWcBXke/block
>              btrfs       10240        36      6112   1% /tmp/tmp.V4FNWcBXke/filesystem
> Expected only one btrfs filesystem
> /home/dschleimer
> 
> [08:09:39 Tue Jun 03 2014] root@HIDDEN /home/dschleimer dschleimer  282 $ PATH=/data/users/dschleimer/coreutils-8.22/src/:$PATH ./repro_instructions.sh
> 1024+0 records in
> 1024+0 records out
> 10485760 bytes (10 MB) copied, 0.0116229 s, 902 MB/s
> 
> WARNING! - Btrfs v0.20-rc1-358-g194aa4a IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using
> 
> SMALL VOLUME: forcing mixed metadata/data groups Created a data/metadata chunk of size 1048576 fs created label (null) on block
>         nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MB Btrfs v0.20-rc1-358-g194aa4a Create subvolume 'filesystem/subvolume'
> 
> 
> 
> Begin unexpected output
> Filesystem                                          1K-blocks  Used Available Use% Mounted on
> /tmp/tmp.o7w6NcN178/filesystem/subvolume/bindsource     10240    36      6112   1% /tmp/tmp.o7w6NcN178/binddest
> Expected report for the main btrfs mount, not the bind-mount
> /tmp/tmp.o7w6NcN178/block                        btrfs      10240         36       6112   1% /tmp/tmp.o7w6NcN178/filesystem
> Expected only one btrfs filesystem
> /home/dschleimer


So the crux of the confusion is that the subvolume has a different device ID.
I.E. a separate virtual file system within the main file system,
that shares storage but are otherwise treated like separate file systems
for hard links etc. Here are the device IDs for your test setup:

  # find -printf "%D %p\n"
  34 .
  63 ./binddest
  62 ./filesystem
  63 ./filesystem/subvolume
  63 ./filesystem/subvolume/directory
  63 ./filesystem/subvolume/bindsource
  34 ./block

When you expose that virtual file system to df
with a bind mount it will be identified separately as you've shown.
BTW it's not specific to bind mounts, as you can see the same
thing by mounting the subvolume separately like:
  mkdir submntdest
  mount -o subvolid=256 -o loop block submntdest
It could be argued that since there are explicit mounts to this
subvolume that one (the shortest) of these is the most appropriate to display?

If you don't mount separately, then df notices that ./filesystem/subvolume is
a "separate mount" due to the different device id, and will display that
as the mount dir and "-" as the device which isn't ideal either.

It's more problematic that the btrfs file system is listed
multiple times, especially with --total which will be incorrect.
We might be able to avoid this problem by taking the first
entry for duplicate device names, when those device names exist.
However I'm worried that there are cases where separate file systems
with separate storage (distinguished by mount options) have the
same device listed. Maybe we could suppress these duplicates by
scanning /proc/self/mountinfo and discarding entries that didn't
have '/' in the fourth column, though that's awkward and I'm
not sure how general it is either.

thanks,
Pádraig.




Information forwarded to bug-coreutils@HIDDEN:
bug#17676; Package coreutils. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 3 Jun 2014 15:34:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 03 11:34:38 2014
Received: from localhost ([127.0.0.1]:42414 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WrqjU-0007hF-RU
	for submit <at> debbugs.gnu.org; Tue, 03 Jun 2014 11:34:37 -0400
Received: from eggs.gnu.org ([208.118.235.92]:47966)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <prvs=12319b5221=dschleimer@HIDDEN>)
 id 1WrqX4-0007Gq-Om
 for submit <at> debbugs.gnu.org; Tue, 03 Jun 2014 11:21:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <prvs=12319b5221=dschleimer@HIDDEN>)
 id 1WrqWt-0002Zj-3M
 for submit <at> debbugs.gnu.org; Tue, 03 Jun 2014 11:21:41 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:47826)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <prvs=12319b5221=dschleimer@HIDDEN>)
 id 1WrqWt-0002Zd-0x
 for submit <at> debbugs.gnu.org; Tue, 03 Jun 2014 11:21:35 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49522)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <prvs=12319b5221=dschleimer@HIDDEN>)
 id 1WrqWm-0005eV-I3
 for bug-coreutils@HIDDEN; Tue, 03 Jun 2014 11:21:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <prvs=12319b5221=dschleimer@HIDDEN>)
 id 1WrqWe-0002Tj-WA
 for bug-coreutils@HIDDEN; Tue, 03 Jun 2014 11:21:28 -0400
Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:29810)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <prvs=12319b5221=dschleimer@HIDDEN>)
 id 1WrqWe-0002SD-JC
 for bug-coreutils@HIDDEN; Tue, 03 Jun 2014 11:21:20 -0400
Received: from pps.filterd (m0044008 [127.0.0.1])
 by mx0a-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id s53FKjeS023895
 for <bug-coreutils@HIDDEN>; Tue, 3 Jun 2014 08:21:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com;
 h=from : to : subject : date
 : message-id : content-type : mime-version; s=facebook;
 bh=sJr0GSgzuTrYdo5E1KDNAf6lsB7xe+1SSECjqnFZ2kg=;
 b=K4iFFrIO0+quB3u3N1o8unHtJuCduADfIgVr1H44MHrHpUckYDi9OyKEgvWGdy+m0nY2
 a33kqX9Cjgp6ee4OOYdxfaL9mrH2+SaaeSvKk1Sfv0dx6jI2/F/7FBdwVCK8DdoEleei
 p06RoZKAzjOMoB43wA7f/RKHoPTFhJfrFIg= 
Received: from mail.thefacebook.com (mailwest.thefacebook.com [173.252.71.148])
 by mx0a-00082601.pphosted.com with ESMTP id 1m91y2j3pq-1
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK)
 for <bug-coreutils@HIDDEN>; Tue, 03 Jun 2014 08:21:17 -0700
Received: from PRN-MBX01-1.TheFacebook.com ([169.254.3.136]) by
 PRN-CHUB07.TheFacebook.com ([fe80::d38:43fc:554e:146a%12]) with mapi id
 14.03.0174.001; Tue, 3 Jun 2014 08:21:16 -0700
From: David Schleimer <dschleimer@HIDDEN>
To: "bug-coreutils@HIDDEN" <bug-coreutils@HIDDEN>
Subject: btrfs subvolumes and bind-mounts make df report incorrect and/or
 extra results
Thread-Topic: btrfs subvolumes and bind-mounts make df report incorrect
 and/or extra results
Thread-Index: Ac9/P2JUaeigNDLcSXifOx2sy/LiEg==
Date: Tue, 3 Jun 2014 15:21:15 +0000
Message-ID: <B647040404E33F408448F7343768AE7A76F70BC5@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.16.4]
Content-Type: multipart/mixed;
 boundary="_002_B647040404E33F408448F7343768AE7A76F70BC5PRNMBX011TheFac_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14,
 0.0.0000
 definitions=2014-06-02_03:2014-06-02,2014-06-02,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0
 kscore.is_bulkscore=6.94094781650278e-12 kscore.compositescore=0
 circleOfTrustscore=0.616 compositescore=0.999449123723516
 urlsuspect_oldscore=0.999449123723516 suspectscore=0
 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0
 kscore.is_spamscore=0 recipient_to_sender_totalscore=0
 recipient_domain_to_sender_domain_totalscore=77 rbsscore=0.999449123723516
 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=7.0.1-1402240000 definitions=main-1406030189
X-FB-Internal: deliver
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.1 (----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Tue, 03 Jun 2014 11:34:35 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.1 (----)

--_002_B647040404E33F408448F7343768AE7A76F70BC5PRNMBX011TheFac_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

When you have btrfs mount where there is a both a subvolume of that mount, =
and the source of a bind-mount under that mount, df will report confusing r=
esults.  It will show results for the bind-mount instead of the main btrfs =
mount when you pass the subvoulme on the command line.  It may (depending o=
n the system) show both the bind-mount and main mount in bare df results.

I've attached a script with the minimal repro instructions.  It needs to be=
 run as root since it (temporarily) mounts filesystems under your tmpdir.

I tested on two machines:
Fedora 20 running kernel 3.14.4-200.fc20.x86_64, against both the system df=
 8.21 and df 8.22 built from source.

Centos 6.4 running a 3.10.39 variant, with significant backports, notably i=
ncluding most btrfs changes from mainline.  Testing against the system df 8=
.4, and df 8.22 again built from source.

On the fedora machine, /etc/mtab is a symlink to /proc/self/mounts.  We see=
 output that refers to the correct block device in all cases.  However, we =
see a report for the bind-mount destination instead of the main btrfs mount=
 when asking specifically for the subvolume path, and see results for both =
the main btrfs filesystem and the bind-mount when we run a bare df.

Transcript of Fedora output:

[root@caitsidhe dschleimer]# ./repro_instructions.sh
1024+0 records in
1024+0 records out
10485760 bytes (10 MB) copied, 0.00963354 s, 1.1 GB/s SMALL VOLUME: forcing=
 mixed metadata/data groups

WARNING! - Btrfs v3.12 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

Turning ON incompat feature 'mixed-bg': mixed data and metadata block group=
s Turning ON incompat feature 'extref': increased hardlink limit per file t=
o 65536 Created a data/metadata chunk of size 1048576 fs created label (nul=
l) on block
        nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MiB Btrfs v3.=
12 Create subvolume 'filesystem/subvolume'



Begin unexpected output
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/loop0         10240    36      6112   1% /tmp/tmp.biUryZcwD9/binddest
Expected report for the main btrfs mount, not the bind-mount
/dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp=
.biUryZcwD9/filesystem
/dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp=
.biUryZcwD9/binddest
Expected only one btrfs filesystem
/home/dschleimer
[root@caitsidhe dschleimer]# PATH=3D/home/dschleimer/Downloads/coreutils-8.=
22/src/:$PATH ./repro_instructions.sh
1024+0 records in
1024+0 records out
10485760 bytes (10 MB) copied, 0.012752 s, 822 MB/s SMALL VOLUME: forcing m=
ixed metadata/data groups

WARNING! - Btrfs v3.12 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

Turning ON incompat feature 'mixed-bg': mixed data and metadata block group=
s Turning ON incompat feature 'extref': increased hardlink limit per file t=
o 65536 Created a data/metadata chunk of size 1048576 fs created label (nul=
l) on block
        nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MiB Btrfs v3.=
12 Create subvolume 'filesystem/subvolume'



Begin unexpected output
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/loop0         10240    36      6112   1% /tmp/tmp.TEBR2D9Vta/binddest
Expected report for the main btrfs mount, not the bind-mount
/dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp=
.TEBR2D9Vta/filesystem
/dev/loop0              btrfs        10240       36      6112   1% /tmp/tmp=
.TEBR2D9Vta/binddest
Expected only one btrfs filesystem
/home/dschleimer

On Centos, /etc/mtab is a plain file.  When asking specifically for the sub=
volume, we see a report for the bind-mount dest which lists the bind-mount =
source as the filesystem.  When we run a bare df, we see only one record wi=
th the file backing the loopback device as the filesystem, but the bind-mou=
nt as the mount-point.

Centos transcript:

[08:03:09 Tue Jun 03 2014] root@HIDDEN /home/dschleimer dschleimer =
 282 $ ./repro_instructions.sh
1024+0 records in
1024+0 records out
10485760 bytes (10 MB) copied, 0.0101568 s, 1.0 GB/s

WARNING! - Btrfs v0.20-rc1-358-g194aa4a IS EXPERIMENTAL WARNING! - see http=
://btrfs.wiki.kernel.org before using

SMALL VOLUME: forcing mixed metadata/data groups Created a data/metadata ch=
unk of size 1048576 fs created label (null) on block
        nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MB Btrfs v0.2=
0-rc1-358-g194aa4a Create subvolume 'filesystem/subvolume'



Begin unexpected output
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/tmp.V4FNWcBXke/filesystem/subvolume/bindsource
                         10240        36      6112   1% /tmp/tmp.V4FNWcBXke=
/binddest
Expected report for the main btrfs mount, not the bind-mount
df: `/mnt/gvfs': Function not implemented /tmp/tmp.V4FNWcBXke/block
             btrfs       10240        36      6112   1% /tmp/tmp.V4FNWcBXke=
/filesystem
Expected only one btrfs filesystem
/home/dschleimer

[08:09:39 Tue Jun 03 2014] root@HIDDEN /home/dschleimer dschleimer =
 282 $ PATH=3D/data/users/dschleimer/coreutils-8.22/src/:$PATH ./repro_inst=
ructions.sh
1024+0 records in
1024+0 records out
10485760 bytes (10 MB) copied, 0.0116229 s, 902 MB/s

WARNING! - Btrfs v0.20-rc1-358-g194aa4a IS EXPERIMENTAL WARNING! - see http=
://btrfs.wiki.kernel.org before using

SMALL VOLUME: forcing mixed metadata/data groups Created a data/metadata ch=
unk of size 1048576 fs created label (null) on block
        nodesize 4096 leafsize 4096 sectorsize 4096 size 10.00MB Btrfs v0.2=
0-rc1-358-g194aa4a Create subvolume 'filesystem/subvolume'



Begin unexpected output
Filesystem                                          1K-blocks  Used Availab=
le Use% Mounted on
/tmp/tmp.o7w6NcN178/filesystem/subvolume/bindsource     10240    36      61=
12   1% /tmp/tmp.o7w6NcN178/binddest
Expected report for the main btrfs mount, not the bind-mount
/tmp/tmp.o7w6NcN178/block                        btrfs      10240         3=
6       6112   1% /tmp/tmp.o7w6NcN178/filesystem
Expected only one btrfs filesystem
/home/dschleimer



--_002_B647040404E33F408448F7343768AE7A76F70BC5PRNMBX011TheFac_
Content-Type: application/octet-stream; name="repro_instructions.sh"
Content-Description: repro_instructions.sh
Content-Disposition: attachment; filename="repro_instructions.sh"; size=606;
	creation-date="Tue, 03 Jun 2014 15:21:04 GMT";
	modification-date="Tue, 03 Jun 2014 15:03:52 GMT"
Content-Transfer-Encoding: base64

IyEvYmluL2Jhc2gKClJFUFJPX0RJUj0kKG1rdGVtcCAtZCkKY2QgJHtSRVBST19ESVJ9CgpkZCBp
Zj0vZGV2L3plcm8gb2Y9YmxvY2sgYnM9MTAyNDAgY291bnQ9MTAyNApta2ZzLmJ0cmZzIGJsb2Nr
Cgpta2RpciBmaWxlc3lzdGVtCm1vdW50IC10IGJ0cmZzIC1vIGxvb3AgYmxvY2sgZmlsZXN5c3Rl
bQoKYnRyZnMgc3Vidm9sdW1lIGNyZWF0ZSBmaWxlc3lzdGVtL3N1YnZvbHVtZQpta2RpciBmaWxl
c3lzdGVtL3N1YnZvbHVtZS97ZGlyZWN0b3J5LGJpbmRzb3VyY2V9Cgpta2RpciBiaW5kZGVzdApt
b3VudCAtLWJpbmQgZmlsZXN5c3RlbS9zdWJ2b2x1bWUvYmluZHNvdXJjZSBiaW5kZGVzdAoKZWNo
bwplY2hvCmVjaG8KZWNobyAiQmVnaW4gdW5leHBlY3RlZCBvdXRwdXQiCmRmIGZpbGVzeXN0ZW0v
c3Vidm9sdW1lL2RpcmVjdG9yeQplY2hvICJFeHBlY3RlZCByZXBvcnQgZm9yIHRoZSBtYWluIGJ0
cmZzIG1vdW50LCBub3QgdGhlIGJpbmQtbW91bnQiCmRmIC1UIHwgZ3JlcCAkUFdECmVjaG8gIkV4
cGVjdGVkIG9ubHkgb25lIGJ0cmZzIGZpbGVzeXN0ZW0iCgp1bW91bnQgYmluZGRlc3QKdW1vdW50
IGZpbGVzeXN0ZW0KY2QgLQpybSAtciAke1JFUFJPX0RJUn0K

--_002_B647040404E33F408448F7343768AE7A76F70BC5PRNMBX011TheFac_--




Acknowledgement sent to David Schleimer <dschleimer@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-coreutils@HIDDEN. Full text available.
Report forwarded to bug-coreutils@HIDDEN:
bug#17676; Package coreutils. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.