Re: finding root filesystem of a subvolume?

[Axel Burri]

On 2017-08-23 14:07, Austin S. Hemmelgarn wrote:
> On 2017-08-22 13:41, Peter Grandi wrote:
> [ ... ]
>> This stupid point relies on ignoring that it is not mandatory to
>> mount the main volume, and that therefore "There is no fixed
>> relationship between the root directory inode of a subvolume and
>> the root directory inode of any other subvolume or the main
>> volume", because the "root directory inode" of the "main volume"
>> may not be mounted at all.
>>
>> This stupid point also relies on ignoring that subvolumes can be
>> mounted *also* under another directory, even if the main volume
>> is mounted somewhere else. Suppose that the following applies:
>>
>>    subvol=5    /local
>>    subvol=383    /local/.backup/home
>>    subvol=383    /mnt/home-backup
>>
>> and you are given the mountpoint '/mnt/home-backup', how can you
>> find the main volume mountpoint '/local' from that?Assuming
>> /mnt/home-backup is mounted and visible in /proc/mounts (your 
> explanation requires it was either mounted directly via a subvol option
> or indirectly via a bind mount), then the following generic method works
> (and should always work on a modern kernel):
> 1. Find it in /proc/mounts or the output of `mount` run without any
> arguments.
> 2. If the mount type is 'bind', the device field will point to the
> source directory.  Using any method you like, figure out what the actual
> mount point that is under is, and repeat from step one with that mount
> point.
> 3. If the mount type is 'btrfs', and 'subvolid=5' is present in the
> mount options (this gets added automatically on any recent kernel), you
> just found the top level subvolume.
> 4. If the mount type is 'btrfs', and 'subvolid=5' is not present in the
> mount options, scan /proc/mounts for other entries with the same device
> value (this is going to be consistent).
> 5. If another entry does exist, and has 'subvolid=5' in the mount
> options, that's the top level subvolume.
> 6. If other entries exist, but 'subvolid=5' not in the mount options for
> any of them, or no other entries exist, the top level volume isn't
> mounted, and you can view it by mounting the device with 'subvolid=5'.
> 
> In the event that you need to know where the next higher level subvolume
> is mounted instead of the root subvolume for the volume, you can use the
> same method, but add the following after step two to figure out what
> subvolid to look for:
> 2b. Run `btrfs subvol show` on the mount point (it by definition has to
> be a subvolume because it's mounted and it's not a bind mount in
> userspace).  Find the 'Top level ID' (note that this just points to the
> next higher subvolume, not the root subvolume) value in the output, and
> use that instead of 5 when looking for 'subvolid=' options.

In order to have a complete view of all mounts, this is what btrbk does
here (which basically matches Austins explanation):

1. Buld a complete tree from:

# btrfs subvolume list -a -u /mnt/home-backup

2. Correlate all subvolume ID's  with mount points (second column) and
"subvolid=" from mount options:

# cat /proc/self/mounts

Now you have a complete view of all mounts. In order to query a given
subvolume, fetch "Subvolume ID" (or "UUID") from:

# btrfs subvolume show /local/.backup/home

see: https://github.com/digint/btrbk/blob/v0.25.1/btrbk
(I apologize that Github has broken display of perl source files at the
time being...)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Austin S. Hemmelgarn]

On 2017-08-22 13:41, Peter Grandi wrote:

[ ... ]


There is no fixed relationship between the root directory
inode of a subvolume and the root directory inode of any
other subvolume or the main volume.



Actually, there is, because it's inherently rooted in the
hierarchy of the volume itself. That root inode for the
subvolume is anchored somewhere under the next higher
subvolume.


This stupid point relies on ignoring that it is not mandatory to
mount the main volume, and that therefore "There is no fixed
relationship between the root directory inode of a subvolume and
the root directory inode of any other subvolume or the main
volume", because the "root directory inode" of the "main volume"
may not be mounted at all.

This stupid point also relies on ignoring that subvolumes can be
mounted *also* under another directory, even if the main volume
is mounted somewhere else. Suppose that the following applies:

   subvol=5 /local
   subvol=383   /local/.backup/home
   subvol=383   /mnt/home-backup

and you are given the mountpoint '/mnt/home-backup', how can you
find the main volume mountpoint '/local' from that?Assuming /mnt/home-backup is mounted and visible in /proc/mounts (your 
explanation requires it was either mounted directly via a subvol option 
or indirectly via a bind mount), then the following generic method works 
(and should always work on a modern kernel):
1. Find it in /proc/mounts or the output of `mount` run without any 
arguments.
2. If the mount type is 'bind', the device field will point to the 
source directory.  Using any method you like, figure out what the actual 
mount point that is under is, and repeat from step one with that mount 
point.
3. If the mount type is 'btrfs', and 'subvolid=5' is present in the 
mount options (this gets added automatically on any recent kernel), you 
just found the top level subvolume.
4. If the mount type is 'btrfs', and 'subvolid=5' is not present in the 
mount options, scan /proc/mounts for other entries with the same device 
value (this is going to be consistent).
5. If another entry does exist, and has 'subvolid=5' in the mount 
options, that's the top level subvolume.
6. If other entries exist, but 'subvolid=5' not in the mount options for 
any of them, or no other entries exist, the top level volume isn't 
mounted, and you can view it by mounting the device with 'subvolid=5'.


In the event that you need to know where the next higher level subvolume 
is mounted instead of the root subvolume for the volume, you can use the 
same method, but add the following after step two to figure out what 
subvolid to look for:
2b. Run `btrfs subvol show` on the mount point (it by definition has to 
be a subvolume because it's mounted and it's not a bind mount in 
userspace).  Find the 'Top level ID' (note that this just points to the 
next higher subvolume, not the root subvolume) value in the output, and 
use that instead of 5 when looking for 'subvolid=' options.


Please explain how '/mnt/home-backup' is indeed "inherently
rooted in the hierarchy of the volume itself", because there is
always a "fixed relationship between the root directory inode of
a subvolume and the root directory inode of any other subvolume
or the main volume".

You did one of three things to mount that:
1. You used a bind mount directly.  In this case, you're not changing 
the relation at all of the subvolume (which is technically not what's 
mounted in this case because a bind mount operates at the VFS layer and 
knows nothing about subvolumes) and it's parent subvolumes.
2. You mounted using 'subvol=.backup/home'.  This in and of itself 
should pretty concisely explain that there is a hierarchical 
relationship between subvolumes.  That path indicates the path in the 
hierarchy of the volume itself used to access the subvolume.
3. You mounted using 'subvolid=383'.  This is the only case where there 
isn't a hierarchical relationship, and just uses the tree ID to 
reference the subvolume.  This is the only case where there isn't some 
direct reference to the parent subvolume.


Note also that this relation is not inherent to the subvolume, but to 
it's parent.  Just like a symbolic link, the reference is in the 
containing object, not the referenced object (although subvolumes do 
store info about what their parent subvolume is).


[ ... ]


Again, it does, it's just not inherently exposed to userspace
unless you mount the top-level subvolume (subvolid=5 and/or
subvol=/ in mount options).


This extra stupid point is based on ignoring that to "mount the
top-level subvolume" relies on knowing already which one is the
"top-level subvolume", which is begging the question.
You have information in /proc/mounts as to what is mounted.  Trace your 
particular path up to that, and then mount the indicated block device 
with `-o subvolid=5`.  The subvolume with ID 5 is _ALWAYS_ the top level 
subvolume for the volume, that's inherently hard coded in the filesystem 
format, so if that's 

Re: finding root filesystem of a subvolume?

[Peter Grandi]

[ ... ]

>> There is no fixed relationship between the root directory
>> inode of a subvolume and the root directory inode of any
>> other subvolume or the main volume.

> Actually, there is, because it's inherently rooted in the
> hierarchy of the volume itself. That root inode for the
> subvolume is anchored somewhere under the next higher
> subvolume.

This stupid point relies on ignoring that it is not mandatory to
mount the main volume, and that therefore "There is no fixed
relationship between the root directory inode of a subvolume and
the root directory inode of any other subvolume or the main
volume", because the "root directory inode" of the "main volume"
may not be mounted at all.

This stupid point also relies on ignoring that subvolumes can be
mounted *also* under another directory, even if the main volume
is mounted somewhere else. Suppose that the following applies:

  subvol=5  /local
  subvol=383/local/.backup/home
  subvol=383/mnt/home-backup

and you are given the mountpoint '/mnt/home-backup', how can you
find the main volume mountpoint '/local' from that?

Please explain how '/mnt/home-backup' is indeed "inherently
rooted in the hierarchy of the volume itself", because there is
always a "fixed relationship between the root directory inode of
a subvolume and the root directory inode of any other subvolume
or the main volume".

[ ... ]

> Again, it does, it's just not inherently exposed to userspace
> unless you mount the top-level subvolume (subvolid=5 and/or
> subvol=/ in mount options).

This extra stupid point is based on ignoring that to "mount the
top-level subvolume" relies on knowing already which one is the
"top-level subvolume", which is begging the question.

[ ... ]
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Roman Mamedov]

On Tue, 22 Aug 2017 17:45:37 +0200
Ulli Horlacher  wrote:

> In perl I have now:
> 
> $root = $volume;
> while (`btrfs subvolume show "$root" 2>/dev/null` !~ /toplevel subvolume/) {
>   $root = dirname($root);
>   last if $root eq '/';
> }
> 
> 

If you are okay with rolling your own solutions like this, take a look at
"btrfs filesystem usage ". It will print the blockdevice used for
mounting the base FS. From that you can find the mountpoint via /proc/mounts.

Performance-wise it seems to work instantly on an almost full 2TB FS.

-- 
With respect,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Ulli Horlacher]

On Tue 2017-08-22 (11:03), Austin S. Hemmelgarn wrote:


> Or alternatively, repeatedly call `btrfs filesystem show` on the path, 
> removing one component from the end each time until you get a zero 
> return code.  The path you called it on that got a zero return code is 
> where the mount is (and thus what filesystem that subvolume is part of), 
> and the output just gave you a list of devices it's on.

"btrfs filesystem show" is relative slow (2.6 s), 
"btrfs subvolume show" is MUCH faster (0.02 s).


In perl I have now:

$root = $volume;
while (`btrfs subvolume show "$root" 2>/dev/null` !~ /toplevel subvolume/) {
  $root = dirname($root);
  last if $root eq '/';
}


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<62494c0c-0c27-5b36-3727-b8755eb2c...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Austin S. Hemmelgarn]

On 2017-08-22 10:43, Peter Grandi wrote:

How do I find the root filesystem of a subvolume?
Example:
root@fex:~# df -T
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104244552 967773976  10% /local/.backup/home

[ ... ]

I know, the root filesystem is /local,


That question is somewhat misunderstood and uses the wrong
concepts and terms. In UNIX filesystems a filesystem "root" is a
directory inode with a number that is local to itself, and can
be "mounted" anywhere, or left unmounted, and that is a property
of the running system, not of the filesystem "root". Usually
UNIX filesystems have a single "root" directory inode.

In the case of Btrfs the main volume and its subvolumes all have
filesystem "root" directory inodes, which may or may not be
"mounted", anywhere the administrators of the running system
pleases, as a property of the running system. There is no fixed
relationship between the root directory inode of a subvolume and
the root directory inode of any other subvolume or the main
volume.
Actually, there is, because it's inherently rooted in the hierarchy of 
the volume itself.  That root inode for the subvolume is anchored 
somewhere under the next higher subvolume.  It's the same concept as 
nested data-sets in ZFS, BTRFS just inherently exposes them at the 
appropriate location in the hierarchy and allows intermediary directories.


Note: in Btrfs terminology "volume" seems to mean both the main
volume and the collection of devices where it and subvolumes are
hosted.
Standard terminology from what I've seen uses 'volume' in the same way 
it's used for ext4, XFS, LVM, MD, and similar things, namely a BTRFS 
'volume' is the collection of devices as well as the sum total of all 
subvolumes on those devices.  This ends up meaning that it implicitly 
refers to the top-level subvolume when there are no other subvolumes, 
and as a result it's come to sometimes mean the top-level subvolume 
(though I rarely see that usage, and would actively discourage it).



but who can I show it by command?


The system does not keep an explicit record of which Btrfs
"root" directory inode is related to which other Btrfs "root"
directory inode in the same volume, whether mounted or
unmounted.
Again, it does, it's just not inherently exposed to userspace unless you 
mount the top-level subvolume (subvolid=5 and/or subvol=/ in mount 
options).  Mount the top level subvolume (once you know what volume the 
subvolume is on), and call `btrfs subvolume list` on it.  The `top level 
N` part of the output from that tells you what the next subvolume up the 
hierarchy is for each subvolume, and the `path` part at the end tells 
you the location within that next higher subvolume where this one is 
rooted.  The output may not make sense though if you don't have the root 
subvolume mounted (because it may be non trivial to trace things up the 
tree).


That relationship has to be discovered by using volume UUIDs,
which are the same for the main subvolume and the other
subvolumes, whether mounted or not, so one has to do:

   * For the indicated mounted subvolume "root" read its UUID.
   * For every mounted filesystem "root", check whether its type
 is 'btrfs' and if it is obtain its UUID.
   * If the UUID is the same, and the subvolume id is '5', that's
 the main subvolume, and terminate.
   * For every block device which is not mounted, check whether it
 has a Btrfs superblock.
   * If the type is 'btrfs' and the volume UUIS is the same as
 that of the subvolume, list the block device.

In the latter case since the main volume is not mounted the only
way to identify it is to list the block devices that host it.
Or alternatively, repeatedly call `btrfs filesystem show` on the path, 
removing one component from the end each time until you get a zero 
return code.  The path you called it on that got a zero return code is 
where the mount is (and thus what filesystem that subvolume is part of), 
and the output just gave you a list of devices it's on.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Peter Grandi]

> How do I find the root filesystem of a subvolume?
> Example:
> root@fex:~# df -T 
> Filesystem Type  1K-blocks  Used Available Use% Mounted on
> -  -1073740800 104244552 967773976  10% /local/.backup/home
[ ... ]
> I know, the root filesystem is /local,

That question is somewhat misunderstood and uses the wrong
concepts and terms. In UNIX filesystems a filesystem "root" is a
directory inode with a number that is local to itself, and can
be "mounted" anywhere, or left unmounted, and that is a property
of the running system, not of the filesystem "root". Usually
UNIX filesystems have a single "root" directory inode.

In the case of Btrfs the main volume and its subvolumes all have
filesystem "root" directory inodes, which may or may not be
"mounted", anywhere the administrators of the running system
pleases, as a property of the running system. There is no fixed
relationship between the root directory inode of a subvolume and
the root directory inode of any other subvolume or the main
volume.

Note: in Btrfs terminology "volume" seems to mean both the main
volume and the collection of devices where it and subvolumes are
hosted.

> but who can I show it by command?

The system does not keep an explicit record of which Btrfs
"root" directory inode is related to which other Btrfs "root"
directory inode in the same volume, whether mounted or
unmounted.

That relationship has to be discovered by using volume UUIDs,
which are the same for the main subvolume and the other
subvolumes, whether mounted or not, so one has to do:

  * For the indicated mounted subvolume "root" read its UUID.
  * For every mounted filesystem "root", check whether its type
is 'btrfs' and if it is obtain its UUID.
  * If the UUID is the same, and the subvolume id is '5', that's
the main subvolume, and terminate.
  * For every block device which is not mounted, check whether it
has a Btrfs superblock.
  * If the type is 'btrfs' and the volume UUIS is the same as
that of the subvolume, list the block device.

In the latter case since the main volume is not mounted the only
way to identify it is to list the block devices that host it.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Austin S. Hemmelgarn]

On 2017-08-22 10:23, Hugo Mills wrote:

On Tue, Aug 22, 2017 at 10:12:25AM -0400, Austin S. Hemmelgarn wrote:

On 2017-08-22 09:53, Ulli Horlacher wrote:

On Tue 2017-08-22 (09:37), Austin S. Hemmelgarn wrote:


root@fex:~# df -T /local/.backup/home
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104252160 967766336  10% /local/.backup/home


Hmm, now I'm really confused, I just checked on the Ubuntu 17.04 and
16.04.3 VM's I have (I only run current and the most recent LTS
version), and neither of them behave like this.


I have this kind of output on all of my Ubuntu hosts:

root@moep:~# grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Ubuntu 16.04.3 LTS"

root@moep:~# df -T /usb/UF/tmp/blubb
Filesystem Type 1K-blocksUsed Available Use% Mounted on
-  - 12581888 3690524   7253700  34% /usb/UF/tmp/blubb

root@moep:~# btrfs subvolume show /usb/UF/tmp/blubb
/usb/UF/tmp/blubb
 Name:   blubb
 UUID:   ecf8c804-d4a3-9948-89fe-b0c1971c25cb
 Parent UUID:-
 Received UUID:  -
 Creation time:  2017-08-22 12:54:16 +0200
 Subvolume ID:   262
 Generation: 23
 Gen at creation:22
 Parent ID:  5
 Top level ID:   5
 Flags:  -
 Snapshot(s):

root@moep:~# dpkg -l | grep btrfs
ii  btrfs-tools 4.4-1ubuntu1
 amd64Checksumming Copy on Write Filesystem utilities


Hmm, interesting.  Are you using qgroups by chance?


I get this behaviour (the "- -") only if it's a non-mounted
subvolume:

hrm@amelia:~ $ df -T .
Filesystem Type  1K-blocks Used Available Use% Mounted on
/dev/sdb1  btrfs 117220284 95271852  18611060  84% /home

hrm@amelia:~ $ sudo btrfs sub crea foo
Create subvolume './foo'

hrm@amelia:~ $ df -T ./foo
Filesystem Type 1K-blocks Used Available Use% Mounted on
-  -117220284 95271880  18611032  84% /home/hrm/foo

hrm@amelia:~ $ sudo mkdir foo/bar
hrm@amelia:~ $ df -T foo/bar
Filesystem Type 1K-blocks Used Available Use% Mounted on
-  -117220284 95271852  18611060  84% /home/hrm/foo

hrm@amelia:~ $ mkdir foo2

hrm@amelia:~ $ sudo mount /dev/sdb1 ./foo2 -o subvol=home/hrm/foo

hrm@amelia:~ $ df -T foo2
Filesystem Type  1K-blocks Used Available Use% Mounted on
/dev/sdb1  btrfs 117220284 95272384  18610528  84% /home/hrm/foo2

Wait, I think I see what's up here.  I was just calling `df -T` without 
pointing at the subvolume (which correctly ignores it because it's not 
actually mounted).  It looks like this is a side effect of the (rather 
irritating) fake mount-point behavior of subvolumes.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Hugo Mills]

On Tue, Aug 22, 2017 at 10:12:25AM -0400, Austin S. Hemmelgarn wrote:
> On 2017-08-22 09:53, Ulli Horlacher wrote:
> >On Tue 2017-08-22 (09:37), Austin S. Hemmelgarn wrote:
> >
> >>>root@fex:~# df -T /local/.backup/home
> >>>Filesystem Type  1K-blocks  Used Available Use% Mounted on
> >>>-  -1073740800 104252160 967766336  10% /local/.backup/home
> >>
> >>Hmm, now I'm really confused, I just checked on the Ubuntu 17.04 and
> >>16.04.3 VM's I have (I only run current and the most recent LTS
> >>version), and neither of them behave like this.
> >
> >I have this kind of output on all of my Ubuntu hosts:
> >
> >root@moep:~# grep PRETTY_NAME /etc/os-release
> >PRETTY_NAME="Ubuntu 16.04.3 LTS"
> >
> >root@moep:~# df -T /usb/UF/tmp/blubb
> >Filesystem Type 1K-blocksUsed Available Use% Mounted on
> >-  - 12581888 3690524   7253700  34% /usb/UF/tmp/blubb
> >
> >root@moep:~# btrfs subvolume show /usb/UF/tmp/blubb
> >/usb/UF/tmp/blubb
> > Name:   blubb
> > UUID:   ecf8c804-d4a3-9948-89fe-b0c1971c25cb
> > Parent UUID:-
> > Received UUID:  -
> > Creation time:  2017-08-22 12:54:16 +0200
> > Subvolume ID:   262
> > Generation: 23
> > Gen at creation:22
> > Parent ID:  5
> > Top level ID:   5
> > Flags:  -
> > Snapshot(s):
> >
> >root@moep:~# dpkg -l | grep btrfs
> >ii  btrfs-tools 4.4-1ubuntu1 
> >amd64Checksumming Copy on Write Filesystem utilities
> >
> Hmm, interesting.  Are you using qgroups by chance?

   I get this behaviour (the "- -") only if it's a non-mounted
subvolume:

hrm@amelia:~ $ df -T .
Filesystem Type  1K-blocks Used Available Use% Mounted on
/dev/sdb1  btrfs 117220284 95271852  18611060  84% /home

hrm@amelia:~ $ sudo btrfs sub crea foo
Create subvolume './foo'

hrm@amelia:~ $ df -T ./foo
Filesystem Type 1K-blocks Used Available Use% Mounted on
-  -117220284 95271880  18611032  84% /home/hrm/foo

hrm@amelia:~ $ sudo mkdir foo/bar
hrm@amelia:~ $ df -T foo/bar
Filesystem Type 1K-blocks Used Available Use% Mounted on
-  -117220284 95271852  18611060  84% /home/hrm/foo

hrm@amelia:~ $ mkdir foo2

hrm@amelia:~ $ sudo mount /dev/sdb1 ./foo2 -o subvol=home/hrm/foo

hrm@amelia:~ $ df -T foo2
Filesystem Type  1K-blocks Used Available Use% Mounted on
/dev/sdb1  btrfs 117220284 95272384  18610528  84% /home/hrm/foo2

   Hugo.

-- 
Hugo Mills | "Your problem is that you have a negative
hugo@... carfax.org.uk | personality."
http://carfax.org.uk/  | "No, I don't!"
PGP: E2AB1DE4  |  Londo and Vir, Babylon 5


signature.asc
Description: Digital signature

Re: finding root filesystem of a subvolume?

[Austin S. Hemmelgarn]

On 2017-08-22 09:53, Ulli Horlacher wrote:

On Tue 2017-08-22 (09:37), Austin S. Hemmelgarn wrote:


root@fex:~# df -T /local/.backup/home
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104252160 967766336  10% /local/.backup/home


Hmm, now I'm really confused, I just checked on the Ubuntu 17.04 and
16.04.3 VM's I have (I only run current and the most recent LTS
version), and neither of them behave like this.


I have this kind of output on all of my Ubuntu hosts:

root@moep:~# grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Ubuntu 16.04.3 LTS"

root@moep:~# df -T /usb/UF/tmp/blubb
Filesystem Type 1K-blocksUsed Available Use% Mounted on
-  - 12581888 3690524   7253700  34% /usb/UF/tmp/blubb

root@moep:~# btrfs subvolume show /usb/UF/tmp/blubb
/usb/UF/tmp/blubb
 Name:   blubb
 UUID:   ecf8c804-d4a3-9948-89fe-b0c1971c25cb
 Parent UUID:-
 Received UUID:  -
 Creation time:  2017-08-22 12:54:16 +0200
 Subvolume ID:   262
 Generation: 23
 Gen at creation:22
 Parent ID:  5
 Top level ID:   5
 Flags:  -
 Snapshot(s):

root@moep:~# dpkg -l | grep btrfs
ii  btrfs-tools 4.4-1ubuntu1
 amd64Checksumming Copy on Write Filesystem utilities


Hmm, interesting.  Are you using qgroups by chance?

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Ulli Horlacher]

On Tue 2017-08-22 (09:37), Austin S. Hemmelgarn wrote:

> > root@fex:~# df -T /local/.backup/home
> > Filesystem Type  1K-blocks  Used Available Use% Mounted on
> > -  -1073740800 104252160 967766336  10% /local/.backup/home
> 
> Hmm, now I'm really confused, I just checked on the Ubuntu 17.04 and 
> 16.04.3 VM's I have (I only run current and the most recent LTS 
> version), and neither of them behave like this.

I have this kind of output on all of my Ubuntu hosts:

root@moep:~# grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Ubuntu 16.04.3 LTS"

root@moep:~# df -T /usb/UF/tmp/blubb
Filesystem Type 1K-blocksUsed Available Use% Mounted on
-  - 12581888 3690524   7253700  34% /usb/UF/tmp/blubb

root@moep:~# btrfs subvolume show /usb/UF/tmp/blubb
/usb/UF/tmp/blubb
Name:   blubb
UUID:   ecf8c804-d4a3-9948-89fe-b0c1971c25cb
Parent UUID:-
Received UUID:  -
Creation time:  2017-08-22 12:54:16 +0200
Subvolume ID:   262
Generation: 23
Gen at creation:22
Parent ID:  5
Top level ID:   5
Flags:  -
Snapshot(s):

root@moep:~# dpkg -l | grep btrfs
ii  btrfs-tools 4.4-1ubuntu1
 amd64Checksumming Copy on Write Filesystem utilities


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<0c35fba9-a514-31dd-a703-17f4727ed...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Marat Khalili]

Hmm, now I'm really confused, I just checked on the Ubuntu 17.04 and 
16.04.3 VM's I have (I only run current and the most recent LTS 
version), and neither of them behave like this. 


Was also shocked, but:


$ lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 16.04.3 LTS
Release:16.04
Codename:xenial

$ df -T | grep /mnt/data/lxc

$ df -T /mnt/data/lxc
Filesystem Type  1K-blocks Used  Available Use% Mounted on
-  -2907008836 90829848 2815107576   4% /mnt/data/lxc


--

With Best Regards,
Marat Khalili

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Marat Khalili]

I have no subvol=/ option at all:
Probably depends on kernel, but I presume missing subvol means the same 
as subvol=/ .



I am only interested in mounted volumes.
If your initial path (/local/.backup/home) is a subvolume but it's not 
itself present in /proc/mounts then it's probably mounted as a part some 
higher-level subvolume, but this higher-level subvolume does not have to 
be root. Do you need volume root or just some higher-level subvolume 
that's mounted?


--

With Best Regards,
Marat Khalili

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Austin S. Hemmelgarn]

On 2017-08-22 09:30, Ulli Horlacher wrote:

On Tue 2017-08-22 (09:27), Austin S. Hemmelgarn wrote:


root@fex:~# df -T
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104244552 967773976  10% /local/.backup/home


 I've never seen the "- -" output from df before. Is this a bind
mount or something?


No, /local/.backup/home is just a btrfs subvolume


It arguably shouldn't be showing up here then if it's not been
explicitly mounted.  I'm betting you're running OpenSUSE or SLES


No:

root@fex:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/;
SUPPORT_URL="http://help.ubuntu.com/;
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;

root@fex:~# df -T /local/.backup/home
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104252160 967766336  10% /local/.backup/home

root@fex:~# type df
df is hashed (/bin/df)

root@fex:~# dpkg -S /bin/df
coreutils: /bin/df

Hmm, now I'm really confused, I just checked on the Ubuntu 17.04 and 
16.04.3 VM's I have (I only run current and the most recent LTS 
version), and neither of them behave like this.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Ulli Horlacher]

On Tue 2017-08-22 (09:27), Austin S. Hemmelgarn wrote:

> >>> root@fex:~# df -T
> >>> Filesystem Type  1K-blocks  Used Available Use% Mounted on
> >>> -  -1073740800 104244552 967773976  10% 
> >>> /local/.backup/home
> >>
> >> I've never seen the "- -" output from df before. Is this a bind
> >> mount or something?
> > 
> > No, /local/.backup/home is just a btrfs subvolume
> 
> It arguably shouldn't be showing up here then if it's not been 
> explicitly mounted.  I'm betting you're running OpenSUSE or SLES

No:

root@fex:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/;
SUPPORT_URL="http://help.ubuntu.com/;
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;

root@fex:~# df -T /local/.backup/home
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104252160 967766336  10% /local/.backup/home

root@fex:~# type df
df is hashed (/bin/df)

root@fex:~# dpkg -S /bin/df
coreutils: /bin/df

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<16778020-9167-b7cc-4768-ee33dca2b...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Austin S. Hemmelgarn]

On 2017-08-22 08:50, Ulli Horlacher wrote:

On Tue 2017-08-22 (12:40), Hugo Mills wrote:

On Tue, Aug 22, 2017 at 02:23:50PM +0200, Ulli Horlacher wrote:


How do I find the root filesystem of a subvolume?
Example:

root@fex:~# df -T
Filesystem Type  1K-blocks  Used Available Use% Mounted on
-  -1073740800 104244552 967773976  10% /local/.backup/home


I've never seen the "- -" output from df before. Is this a bind
mount or something?


No, /local/.backup/home is just a btrfs subvolume
It arguably shouldn't be showing up here then if it's not been 
explicitly mounted.  I'm betting you're running OpenSUSE or SLES and 
they finally got their df integration done, as that df output absolutely 
matches the type of brain-dead handling of BTRFS I'm coming to expect 
out of them.



Note to SUSE people reading this:  You should be including actual 
information for at least the Type field, and ideally the Filesystem 
field too.  People expect this to behave reasonably, and not listing any 
info about where the 'mount' originated or what it is is not reasonable.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Ulli Horlacher]

On Tue 2017-08-22 (15:58), Marat Khalili wrote:
> On 22/08/17 15:50, Ulli Horlacher wrote:
> 
> > It seems, I have to scan the subvolume path upwards until I found a real
> > mount point,
> 
> I think searching /proc/mounts for the same device and subvol=/ in 
> options is most straightforward.

I have no subvol=/ option at all:

root@fex:~# grep btrfs /proc/mounts
/dev/sdf1 /backup btrfs rw,relatime,compress=zlib,space_cache 0 0
/dev/sde1 /local btrfs rw,relatime,compress=zlib,space_cache 0 0


> But what makes you think it's mounted at all?

I am only interested in mounted volumes.

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Marat Khalili]

On 22/08/17 15:50, Ulli Horlacher wrote:

It seems, I have to scan the subvolume path upwards until I found a real
mount point,
I think searching /proc/mounts for the same device and subvol=/ in 
options is most straightforward. But what makes you think it's mounted 
at all?


--

With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Ulli Horlacher]

On Tue 2017-08-22 (12:40), Hugo Mills wrote:
> On Tue, Aug 22, 2017 at 02:23:50PM +0200, Ulli Horlacher wrote:
> 
> > How do I find the root filesystem of a subvolume?
> > Example:
> > 
> > root@fex:~# df -T 
> > Filesystem Type  1K-blocks  Used Available Use% Mounted on
> > -  -1073740800 104244552 967773976  10% /local/.backup/home
> 
>I've never seen the "- -" output from df before. Is this a bind
> mount or something?

No, /local/.backup/home is just a btrfs subvolume


> > I know, the root filesystem is /local, but who can I show it by command?
> 
>Probably in /proc/self/mountinfo 

root@fex:~# grep home /proc/self/mountinfo
root@fex:~# grep btrfs /proc/self/mountinfo
31 22 0:23 / /backup rw,relatime - btrfs /dev/sdf1 rw,compress=zlib,space_cache
32 22 0:26 / /local rw,relatime - btrfs /dev/sde1 rw,compress=zlib,space_cache

No information about the subvolume /local/.backup/home

It seems, I have to scan the subvolume path upwards until I found a real
mount point,

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20170822124036.ga32...@carfax.org.uk>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finding root filesystem of a subvolume?

[Hugo Mills]

On Tue, Aug 22, 2017 at 02:23:50PM +0200, Ulli Horlacher wrote:
> How do I find the root filesystem of a subvolume?
> Example:
> 
> root@fex:~# df -T 
> Filesystem Type  1K-blocks  Used Available Use% Mounted on
> -  -1073740800 104244552 967773976  10% /local/.backup/home

   I've never seen the "- -" output from df before. Is this a bind
mount or something?

> root@fex:~# btrfs subvolume show /local/.backup/home
> /local/.backup/home
> Name:   home
> uuid:   f86a2db0-6a82-124f-9a71-1cd4c20fd6fb
> Parent uuid:ba4d388f-44bf-7b46-b2b8-00e2a9a87181
> Creation time:  2017-08-10 22:19:15
> Object ID:  383
> Generation (Gen):   148
> Gen at creation:148
> Parent: 5
> Top Level:  5
> Flags:  readonly
> Snapshot(s):
> 
> 
> I know, the root filesystem is /local, but who can I show it by command?

   Probably in /proc/self/mountinfo -- that should give you the full
set of applied mount options, plus the original source for the mount
(which will be a block device for most filesystem mounts, a path for
bind mounts, or something FS-specific for network filesystems).

   Hugo.

-- 
Hugo Mills | And what rough beast, its hour come round at last /
hugo@... carfax.org.uk | slouches towards Bethlehem, to be born?
http://carfax.org.uk/  |
PGP: E2AB1DE4  | W.B. Yeats, The Second Coming


signature.asc
Description: Digital signature