Re: Can I see what device was used to mount btrfs?

[Andrei Borzenkov]

03.05.2017 21:43, Chris Murphy пишет:
> If I understand the bug report correctly, the user specifies mounting
> by label which then systemd is converting into /dev/dm-0 (because it's
> a two LUKS devices Btrfs volume).
> 

No, that's not the problem.

The actual reason for report is that systemd shows device, which is
apparently (as shown in "systemctl status foo.mount" and in
/proc/self/mountinfo for /foo) used to mount /foo, as non-existent.
"Tentative" state is used by systemd to represent devices that do exist
but were not announced to it (or announced with SYSTEMD_READY=0).

To understand why it happens you need to know how systemd handles btrfs
mounts. udev rule calls "btrfs device ready" and if it says that
filesystem is not yet ready to be mounted, it sets SYSTEMD_READY=0. When
final device that makes btrfs complete appears, it is announced to
systemd. Usually this last device also "wins" when creating device
aliases, so LABEL/UUID is resolved to it. When systemd sees this device
it proceeds with mount.

Now as we have seen device that is shown in /proc/self/mountinfo is
*not* the same device that was used to actually mount filesystem. So in
case of bug report all links point to /dev/dm-1 but /proc/self/mountinfo
show /dev/dm-0. But /dev/dm-0 "does not esist" (when it was scanned
btrfs was not ready yet) hence the confusion.

Now related problem (which was "helpfully" closed as duplicate without
understanding the real issue) is that creation of those links itself is
not deterministic.

> Why not convert the fstab mount by label request, into a /dev/by-uuid/
> path; and then systemd calls mount with -u,--uuid mount option rather
> than the block device?

It absolutely does not matter. Internally util-linux will convert it to
/dev/disk/by-xxx anyway. And currently systemd needs device name to wait
for so it needs to resolve it.

> I'd think this is better no matter what the
> file system is, but certainly with Btrfs and possibly ZFS. That makes
> the device discovery problem not systemd's problem to hassle with.
> 
> 
> 
> Chris Murphy
> 
> 
> 
> 
> On Wed, May 3, 2017 at 11:05 AM, Goffredo Baroncelli  
> wrote:
>> On 2017-05-02 22:15, Kai Krakow wrote:
 For example, it would be possible to implement a sane check that
 prevent to mount a btrfs filesystem if two devices exposes the same
 UUID...
>>> Ideally, the btrfs wouldn't even appear in /dev until it was assembled
>>> by udev. But apparently that's not the case, and I think this is where
>>> the problems come from. I wish, btrfs would not show up as device nodes
>>> in /dev that the mount command identified as btrfs. Instead, btrfs
>>> would expose (probably through udev) a device node
>>> in /dev/btrfs/fs_identifier when it is ready.
>>
>>
>> And what if udev fails to assemble the devices (for example because not all 
>> the disks are available or because there are two disks with the same uuid) ?
>> And if the user can't access the disks, how he could solve the issues (i.e. 
>> two disk with the same uuid)
>>
>> I think that udev should be put out of the game of assembling the disks. For 
>> the following reasons:
>> 1) udev is not developed by the BTRFS community where the btrfs knowledges 
>> are; there are a lot of corner cases which are not clear to the btrfs 
>> developers; how these case could be more clearer to the udev developers (who 
>> indeed are very smart guys) ?
>> 2) I don't think that udev is flexible enough to handle all the cases (e.g.: 
>> two disks with the same uuid,  missing devices)
>> 3) udev works quite well at handling the device appearing; why it should be 
>> involved in the filesystem assembling ?
>>
>>
>> BR
>> G.Baroncelli
>>
>>
>> --
>> gpg @keyserver.linux.it: Goffredo Baroncelli 
>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
>> --
>> 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
> 
> 
> 

--
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: Can I see what device was used to mount btrfs?

[Chris Murphy]

qemu-kvm (Fedora 26 pre-beta guest and host)
systemd-233-3.fc26.x86_64
kernel-4.11.0-0.rc8.git0.1.fc26.x86_64

The guest installed OS uses ext4, and boot parameters rd.udev.debug
systemd.log_level=debug so we can see the entirety of Btrfs device
discovery and module loading. Using virsh I can hot plug a virtio
device. There are two devices, vg/test1 and vg/test2 which have a
single Btrfs volume made with:

mkfs.btrfs -L themirror -draid1 -mraid1 /dev/vg/test1 /dev/vg/test2

When I 'virsh attach-device' to hot add only /dev/vg/test1, I get
output that's in test1.log attached.

When I 'vrish attach-device' to hot add /dev/vg/test1, I get output
found in test2.log also attached.

These appear as /dev/vdb and /dev/vdc respectively in the guest.

And then 'mount /dev/vdb /mnt' followed 10 seconds later with 'umount
/mnt' and that's in mount-umount.log, attached.

Keep an eye on the monotonic times, the entries aren't always in order.

Note in test2.log how there is a replacement of the label and uuid
links. They originally point to /dev/vdb, but upon 2nd device
appearing...

[  300.676608] f26.localdomain systemd-udevd[1797]: found 'b252:16'
claiming 
'/run/udev/links/\x2fdisk\x2fby-uuid\x2fe5eb17cb-40d7-48c8-ab84-925f565edf93'
[  300.676681] f26.localdomain systemd-udevd[1797]: creating link
'/dev/disk/by-uuid/e5eb17cb-40d7-48c8-ab84-925f565edf93' to '/dev/vdc'
[  300.676752] f26.localdomain systemd-udevd[1797]: atomically replace
'/dev/disk/by-uuid/e5eb17cb-40d7-48c8-ab84-925f565edf93'

After umounting, I tried another mount this time mounting /dev/vdc.
The kernel recognizes vdc...

[ 1719.716027] f26.localdomain kernel: BTRFS info (device vdc): disk
space caching is enabled
[ 1719.716030] f26.localdomain kernel: BTRFS info (device vdc): has
skinny extents

But systemd still refers to dev-vdb.device in the mount and umount
process, /dev/vdc is not mentioned. And both df and findmnt and
mountinfo show /dev/vdb.

[  134.574002] f26.localdomain kernel: pci :00:0a.0: [1af4:1001] type 00 class 0x01
[  134.576003] f26.localdomain kernel: pci :00:0a.0: reg 0x10: [io  0x-0x003f]
[  134.576042] f26.localdomain kernel: pci :00:0a.0: reg 0x14: [mem 0x-0x0fff]
[  134.576154] f26.localdomain kernel: pci :00:0a.0: reg 0x20: [mem 0x-0x3fff 64bit pref]
[  134.579091] f26.localdomain kernel: pci :00:0a.0: BAR 4: assigned [mem 0x8000-0x80003fff 64bit pref]
[  134.579279] f26.localdomain kernel: pci :00:0a.0: BAR 1: assigned [mem 0x80004000-0x80004fff]
[  134.579305] f26.localdomain kernel: pci :00:0a.0: BAR 0: assigned [io  0x1000-0x103f]
[  134.579522] f26.localdomain kernel: virtio-pci :00:0a.0: enabling device ( -> 0003)
[  135.122898] f26.localdomain systemd-udevd[548]: seq 2093 queued, 'add' 'pci'
[  135.123173] f26.localdomain systemd-udevd[548]: Validate module index
[  135.123326] f26.localdomain systemd-udevd[548]: Check if link configuration needs reloading.
[  135.123463] f26.localdomain systemd-udevd[548]: seq 2093 forked new worker [1791]
[  135.123604] f26.localdomain systemd-udevd[1791]: seq 2093 running
[  135.123724] f26.localdomain systemd-udevd[1791]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:15
[  135.123845] f26.localdomain systemd-udevd[1791]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5
[  135.123969] f26.localdomain systemd-udevd[1791]: created db file '/run/udev/data/+pci::00:0a.0' for '/devices/pci:00/:00:0a.0'
[  135.124100] f26.localdomain systemd-udevd[1791]: Execute 'load' 'pci:v1AF4d1001sv1AF4sd0002bc01sc00i00'
[  135.124204] f26.localdomain systemd-udevd[1791]: Inserted 'virtio_pci'
[  135.124313] f26.localdomain systemd-udevd[1791]: passed device to netlink monitor 0x5580e6cf9ac0
[  135.124432] f26.localdomain systemd-udevd[1791]: seq 2093 processed
[  135.124550] f26.localdomain systemd-udevd[548]: cleanup idle workers
[  135.124857] f26.localdomain systemd-udevd[1791]: Unload module index
[  135.124972] f26.localdomain systemd-udevd[1791]: Unloaded link configuration context.
[  135.125096] f26.localdomain systemd-udevd[548]: worker [1791] exited
[  135.150783] f26.localdomain systemd-udevd[548]: seq 2094 queued, 'add' 'virtio'
[  135.151698] f26.localdomain systemd-udevd[548]: seq 2094 forked new worker [1793]
[  135.152200] f26.localdomain systemd-udevd[548]: seq 2095 queued, 'add' 'bdi'
[  135.152856] f26.localdomain systemd-udevd[1793]: seq 2094 running
[  135.154059] f26.localdomain systemd-udevd[1793]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:15
[  135.154896] f26.localdomain systemd-udevd[1793]: IMPORT builtin 'hwdb' returned non-zero
[  135.156140] f26.localdomain systemd-udevd[548]: seq 2095 forked new worker [1794]
[  135.156582] f26.localdomain systemd-udevd[548]: seq 2096 queued, 'add' 'block'
[  135.156865] f26.localdomain systemd-udevd[1793]: RUN 'kmod load $env{MODALIAS}' 

Re: Can I see what device was used to mount btrfs?

[Duncan]

Chris Murphy posted on Wed, 03 May 2017 12:43:36 -0600 as excerpted:

> If I understand the bug report correctly, the user specifies mounting by
> label which then systemd is converting into /dev/dm-0 (because it's a
> two LUKS devices Btrfs volume).
> 
> Why not convert the fstab mount by label request, into a /dev/by-uuid/
> path; and then systemd calls mount with -u,--uuid mount option rather
> than the block device? I'd think this is better no matter what the file
> system is, but certainly with Btrfs and possibly ZFS. That makes the
> device discovery problem not systemd's problem to hassle with.

You're forgetting one thing:  mount doesn't handle either label or uuid 
(or similar partlabel/partuid/etc) mounting on its own -- it interprets 
all of these as the appropriate /dev/disk/by-* symlink references, 
dereferences those to the canonical device name, and actually mounts 
using that.

See the mount (8) manpage, relatively near the top under "Indicating the 
device", the relevant quote being "The mount (8) command internally uses 
udev symlinks, so the use of symlinks in /etc/fstab has no advantage over 
[LABEL=, UUID=, etc] tags."

And of course it's systemd's udev component that sets up those /dev/disk/
by-* symlinks in the first place.

So converting mount-by-label requests to mount-by-uuid requests gets you 
exactly nowhere, as underneath the covers they're both using the the same 
level udev-generated /dev/disk/by-* symlinks to get the canonical device 
name, so not only do you fail to get rid of the systemd/udev involvement, 
you fail to even reduce abstraction to a lower level.

Not to mention that newer systemd is apparently using its own mount-
alternative now, and doesn't actually call the traditional mount binary 
any more, at least for supported filesystem types.  I'm not qualified to 
argue the case for or against that, but it's apparently happening now, 
and regardless of where one stands on the merits, it's certainly 
inserting systemd even farther into the mount process for relatively 
complex and fuller-featured filesystems such as btrfs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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: Can I see what device was used to mount btrfs?

[Austin S. Hemmelgarn]

On 2017-05-03 14:12, Andrei Borzenkov wrote:

03.05.2017 14:26, Austin S. Hemmelgarn пишет:

On 2017-05-02 15:50, Goffredo Baroncelli wrote:

On 2017-05-02 20:49, Adam Borowski wrote:

It could be some daemon that waits for btrfs to become complete.  Do we
have something?

Such a daemon would also have to read the chunk tree.


I don't think that a daemon is necessary. As proof of concept, in the
past I developed a mount helper [1] which handled the mount of a btrfs
filesystem:
this handler first checks if the filesystem is a multivolume devices,
if so it waits that all the devices are appeared. Finally mount the
filesystem.


It's not so simple -- such a btrfs device would have THREE states:

1. not mountable yet (multi-device with not enough disks present)
2. mountable ro / rw-degraded
3. healthy


My mount.btrfs could be "programmed" to wait a timeout, then it mounts
the filesystem as degraded if not all devices are present. This is a
very simple strategy, but this could be expanded.

I am inclined to think that the current approach doesn't fit well the
btrfs requirements.  The roles and responsibilities are spread to too
much layer (udev, systemd, mount)... I hoped that my helper could be
adopted in order to concentrate all the responsibility to only one
binary; this would reduce the interface number with the other
subsystem (eg systemd, udev).

The primary problem is that systemd treats BTRFS like a block-layer
instead of a filesystem (so it assumes all devices need to be present),
and that it doesn't trust the kernel's mount function to work correctly.


My understanding is that before kernel mount can succeed for
multi-device btrfs, kernel must be made aware of devices that comprise
this filesystem. This is done by using (equivalent of) "btrfs device
scan" or "btrfs device ready". Am I wrong here?
That is correct, the kernel needs to be notified about the devices via 
'btrfs device scan' (or directly with the ioctl that calls).  Udev calls 
this automatically on newly connected block devices though, so currently 
there is no reason manually run it on most systems.  Ideally, this 
should be in a mount helper and possibly triggered by 'btrfs filesystem 
show'.  Unless you're mounting a BTRFS volume or listing what the kernel 
knows about, there is no reason the kernel needs to be tracking the FS, 
so there is no point in regularly wasting time in udev processing by 
scanning all newly connected devices.


As far as 'btrfs device ready', that only tells you if the kernel thinks 
the filesystem is mountable _and_ not degraded.  It's usually correct, 
but watching that has the usual TOCTOU races present in any kind of 
status checking system, and it's useless if you want to mount degraded.



 As a result, it assumes that the mount operation will fail if it
doesn't see all the devices instead of just trying it like it should.


So do you suggest that mount will succeed even if kernel is not made
aware of all devices? If not, could you elaborate how btrfs should be
mounted on boot - we must give mount command some device, right? How
should we chose this device?

See my above comment on kernel awareness.

If you have 'degraded' in the mount options, the mount can succeed even 
if not all the devices are present.  Systemd refuses to even try the 
mount if it doesn't see all the devices, and then *unmounts* the FS if 
it gets mounted manually and not all devices are present.  Both of these 
are undesired behaviors for many people (the second more than the first).


I think I've outlined my thoughts on all of this somewhere before, but I 
can't find them, so I might as well do so here:


1. Device scanning should be done by a mount helper, not udev.  This 
closes a serious data safety/security issue present in the current 
combined implementation (if you plug in a device that has the same UUID 
as an existing BTRFS volume on the system and both volumes are marked as 
multi-device, you can cause data loss in the existing volume),  allows 
for more concise tracking of devices, and also eliminates the need for 
system-wide scanning in some cases (if you use 'device=' mount options 
that cover all the devices in the filesystem).  It also saves some time 
in processing of uevents for hot-plugged devices.


2. Systemd should not default to unmounting filesystems it thinks aren't 
ready yet when they've been manually mounted.  This behavior is highly 
counter-intuitive for most users ('The mount command didn't complain and 
returned 0 and dmesg has no errors, why the hell is the filesystem I 
just mounted not mounted?'), and more importantly in this context, makes 
it impossible to manually repair a BTRFS filesystem that's listed in a 
mount unit without dropping to emergency mode, which largely defeats the 
purpose of using a multi-device filesystem that can be repaired online.


3. For BTRFS, and possibly under special circumstances with other 
filesystems (partially present ZFS pool, partially assembled LVM or 

Re: Can I see what device was used to mount btrfs?

[Chris Murphy]

If I understand the bug report correctly, the user specifies mounting
by label which then systemd is converting into /dev/dm-0 (because it's
a two LUKS devices Btrfs volume).

Why not convert the fstab mount by label request, into a /dev/by-uuid/
path; and then systemd calls mount with -u,--uuid mount option rather
than the block device? I'd think this is better no matter what the
file system is, but certainly with Btrfs and possibly ZFS. That makes
the device discovery problem not systemd's problem to hassle with.



Chris Murphy




On Wed, May 3, 2017 at 11:05 AM, Goffredo Baroncelli  wrote:
> On 2017-05-02 22:15, Kai Krakow wrote:
>>> For example, it would be possible to implement a sane check that
>>> prevent to mount a btrfs filesystem if two devices exposes the same
>>> UUID...
>> Ideally, the btrfs wouldn't even appear in /dev until it was assembled
>> by udev. But apparently that's not the case, and I think this is where
>> the problems come from. I wish, btrfs would not show up as device nodes
>> in /dev that the mount command identified as btrfs. Instead, btrfs
>> would expose (probably through udev) a device node
>> in /dev/btrfs/fs_identifier when it is ready.
>
>
> And what if udev fails to assemble the devices (for example because not all 
> the disks are available or because there are two disks with the same uuid) ?
> And if the user can't access the disks, how he could solve the issues (i.e. 
> two disk with the same uuid)
>
> I think that udev should be put out of the game of assembling the disks. For 
> the following reasons:
> 1) udev is not developed by the BTRFS community where the btrfs knowledges 
> are; there are a lot of corner cases which are not clear to the btrfs 
> developers; how these case could be more clearer to the udev developers (who 
> indeed are very smart guys) ?
> 2) I don't think that udev is flexible enough to handle all the cases (e.g.: 
> two disks with the same uuid,  missing devices)
> 3) udev works quite well at handling the device appearing; why it should be 
> involved in the filesystem assembling ?
>
>
> BR
> G.Baroncelli
>
>
> --
> gpg @keyserver.linux.it: Goffredo Baroncelli 
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
> --
> 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



-- 
Chris Murphy
--
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: Can I see what device was used to mount btrfs?

[Andrei Borzenkov]

03.05.2017 14:26, Austin S. Hemmelgarn пишет:
> On 2017-05-02 15:50, Goffredo Baroncelli wrote:
>> On 2017-05-02 20:49, Adam Borowski wrote:
 It could be some daemon that waits for btrfs to become complete.  Do we
 have something?
>>> Such a daemon would also have to read the chunk tree.
>>
>> I don't think that a daemon is necessary. As proof of concept, in the
>> past I developed a mount helper [1] which handled the mount of a btrfs
>> filesystem:
>> this handler first checks if the filesystem is a multivolume devices,
>> if so it waits that all the devices are appeared. Finally mount the
>> filesystem.
>>
>>> It's not so simple -- such a btrfs device would have THREE states:
>>>
>>> 1. not mountable yet (multi-device with not enough disks present)
>>> 2. mountable ro / rw-degraded
>>> 3. healthy
>>
>> My mount.btrfs could be "programmed" to wait a timeout, then it mounts
>> the filesystem as degraded if not all devices are present. This is a
>> very simple strategy, but this could be expanded.
>>
>> I am inclined to think that the current approach doesn't fit well the
>> btrfs requirements.  The roles and responsibilities are spread to too
>> much layer (udev, systemd, mount)... I hoped that my helper could be
>> adopted in order to concentrate all the responsibility to only one
>> binary; this would reduce the interface number with the other
>> subsystem (eg systemd, udev).
> The primary problem is that systemd treats BTRFS like a block-layer
> instead of a filesystem (so it assumes all devices need to be present),
> and that it doesn't trust the kernel's mount function to work correctly.

My understanding is that before kernel mount can succeed for
multi-device btrfs, kernel must be made aware of devices that comprise
this filesystem. This is done by using (equivalent of) "btrfs device
scan" or "btrfs device ready". Am I wrong here?

>  As a result, it assumes that the mount operation will fail if it
> doesn't see all the devices instead of just trying it like it should.

So do you suggest that mount will succeed even if kernel is not made
aware of all devices? If not, could you elaborate how btrfs should be
mounted on boot - we must give mount command some device, right? How
should we chose this device?

--
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: Can I see what device was used to mount btrfs?

[Goffredo Baroncelli]

On 2017-05-02 22:15, Kai Krakow wrote:
>> For example, it would be possible to implement a sane check that
>> prevent to mount a btrfs filesystem if two devices exposes the same
>> UUID... 
> Ideally, the btrfs wouldn't even appear in /dev until it was assembled
> by udev. But apparently that's not the case, and I think this is where
> the problems come from. I wish, btrfs would not show up as device nodes
> in /dev that the mount command identified as btrfs. Instead, btrfs
> would expose (probably through udev) a device node
> in /dev/btrfs/fs_identifier when it is ready.


And what if udev fails to assemble the devices (for example because not all the 
disks are available or because there are two disks with the same uuid) ?
And if the user can't access the disks, how he could solve the issues (i.e. two 
disk with the same uuid)

I think that udev should be put out of the game of assembling the disks. For 
the following reasons:
1) udev is not developed by the BTRFS community where the btrfs knowledges are; 
there are a lot of corner cases which are not clear to the btrfs developers; 
how these case could be more clearer to the udev developers (who indeed are 
very smart guys) ?
2) I don't think that udev is flexible enough to handle all the cases (e.g.: 
two disks with the same uuid,  missing devices)
3) udev works quite well at handling the device appearing; why it should be 
involved in the filesystem assembling ?


BR
G.Baroncelli


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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: Can I see what device was used to mount btrfs?

[Austin S. Hemmelgarn]

On 2017-05-02 16:15, Kai Krakow wrote:

Am Tue, 2 May 2017 21:50:19 +0200
schrieb Goffredo Baroncelli :


On 2017-05-02 20:49, Adam Borowski wrote:

It could be some daemon that waits for btrfs to become complete.
Do we have something?

Such a daemon would also have to read the chunk tree.


I don't think that a daemon is necessary. As proof of concept, in the
past I developed a mount helper [1] which handled the mount of a
btrfs filesystem: this handler first checks if the filesystem is a
multivolume devices, if so it waits that all the devices are
appeared. Finally mount the filesystem.


It's not so simple -- such a btrfs device would have THREE states:

1. not mountable yet (multi-device with not enough disks present)
2. mountable ro / rw-degraded
3. healthy


My mount.btrfs could be "programmed" to wait a timeout, then it
mounts the filesystem as degraded if not all devices are present.
This is a very simple strategy, but this could be expanded.

I am inclined to think that the current approach doesn't fit well the
btrfs requirements.  The roles and responsibilities are spread to too
much layer (udev, systemd, mount)... I hoped that my helper could be
adopted in order to concentrate all the responsibility to only one
binary; this would reduce the interface number with the other
subsystem (eg systemd, udev).

For example, it would be possible to implement a sane check that
prevent to mount a btrfs filesystem if two devices exposes the same
UUID...


Ideally, the btrfs wouldn't even appear in /dev until it was assembled
by udev. But apparently that's not the case, and I think this is where
the problems come from. I wish, btrfs would not show up as device nodes
in /dev that the mount command identified as btrfs. Instead, btrfs
would expose (probably through udev) a device node
in /dev/btrfs/fs_identifier when it is ready.

Apparently, the core problem of how to handle degraded btrfs still
remains. Maybe it could be solved by adding more stages of btrfs nodes,
like /dev/btrfs-incomplete (for unusable btrfs), /dev/btrfs-degraded
(for btrfs still missing devices but at least one stripe of btrfs raid
available) and /dev/btrfs as the final stage. That way, a mount process
could wait for a while, and if the device doesn't appear, it tries the
degraded stage instead. If the fs is opened from the degraded dev node
stage, udev (or other processes) that scan for devices should stop
assembling the fs if they still do so.
That won't work though because BTRFS is a _filesystem_ not a block 
layer.  We don't have any way of hiding things.  Even if we did, we 
would still need to parse the superblocks and chunk tree, and at that 
point, it just makes more sense to try to mount the FS instead.  IOW, 
the correct way to determine if a BTRFS volume is mountable is to try to 
mount it, not to wait and try to find all the devices.


bcache has a similar approach by hiding an fs within a protective
superblock. Unless bcache is setup, the fs won't show up in /dev, and
that fs won't be visible by other means. Btrfs should do something
similar and only show a single device node if assembled completely. The
component devices would have superblocks ignored by mount, and only the
final node would expose a virtual superblock and the compound device
after it. Of course, this makes things like compound device resizing
more complicated maybe even impossible.
Except there is no 'btrfs' device node for a filesystem.  The only node 
is /dev/btrfs-control, which is used for a small handful of things that 
don't involve the mountability of any filesystem.  To reiterate, we are 
_NOT_ a block layer, so there is _NO_ associated block device for an 
assembled multi-device volume, nor should there be.


If I'm not totally wrong, I think this is also how zfs exposes its
pools. You need user space tools to make the fs pools visible in the
tree. If zfs is incomplete, there's nothing to mount, and thus no race
condition. But I never tried zfs seriously, so I do not know.
For zvols, yes, this is how it works.  For actual filesystem datasets, 
it behaves almost identically to BTRFS AFAIK.


--
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: Can I see what device was used to mount btrfs?

[Austin S. Hemmelgarn]

On 2017-05-02 15:50, Goffredo Baroncelli wrote:

On 2017-05-02 20:49, Adam Borowski wrote:

It could be some daemon that waits for btrfs to become complete.  Do we
have something?

Such a daemon would also have to read the chunk tree.


I don't think that a daemon is necessary. As proof of concept, in the past I 
developed a mount helper [1] which handled the mount of a btrfs filesystem:
this handler first checks if the filesystem is a multivolume devices, if so it 
waits that all the devices are appeared. Finally mount the filesystem.


It's not so simple -- such a btrfs device would have THREE states:

1. not mountable yet (multi-device with not enough disks present)
2. mountable ro / rw-degraded
3. healthy


My mount.btrfs could be "programmed" to wait a timeout, then it mounts the 
filesystem as degraded if not all devices are present. This is a very simple strategy, 
but this could be expanded.

I am inclined to think that the current approach doesn't fit well the btrfs 
requirements.  The roles and responsibilities are spread to too much layer 
(udev, systemd, mount)... I hoped that my helper could be adopted in order to 
concentrate all the responsibility to only one binary; this would reduce the 
interface number with the other subsystem (eg systemd, udev).
The primary problem is that systemd treats BTRFS like a block-layer 
instead of a filesystem (so it assumes all devices need to be present), 
and that it doesn't trust the kernel's mount function to work correctly. 
 As a result, it assumes that the mount operation will fail if it 
doesn't see all the devices instead of just trying it like it should.


For example, it would be possible to implement a sane check that prevent to 
mount a btrfs filesystem if two devices exposes the same UUID...


BR
G.Baroncelli

[1] See "[RFC][PATCH v2] mount.btrfs helper" thread ( 
https://marc.info/?l=linux-btrfs=141736989508243=2 )



--
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: Can I see what device was used to mount btrfs?

[Adam Borowski]

On Tue, May 02, 2017 at 10:15:06PM +0200, Kai Krakow wrote:
> Ideally, the btrfs wouldn't even appear in /dev until it was assembled
> by udev. But apparently that's not the case, and I think this is where
> the problems come from. I wish, btrfs would not show up as device nodes
> in /dev that the mount command identified as btrfs. Instead, btrfs
> would expose (probably through udev) a device node
> in /dev/btrfs/fs_identifier when it is ready.
> 
> Apparently, the core problem of how to handle degraded btrfs still
> remains. Maybe it could be solved by adding more stages of btrfs nodes,
> like /dev/btrfs-incomplete (for unusable btrfs), /dev/btrfs-degraded
> (for btrfs still missing devices but at least one stripe of btrfs raid
> available) and /dev/btrfs as the final stage.

The problem is, we can't tell these states apart other than doing the vast
majority of mount's work.  As I described earlier in this thread, even the
"fully available" stage is not trivial.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.
--
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: Can I see what device was used to mount btrfs?

[Kai Krakow]

Am Tue, 2 May 2017 21:50:19 +0200
schrieb Goffredo Baroncelli :

> On 2017-05-02 20:49, Adam Borowski wrote:
> >> It could be some daemon that waits for btrfs to become complete.
> >> Do we have something?  
> > Such a daemon would also have to read the chunk tree.  
> 
> I don't think that a daemon is necessary. As proof of concept, in the
> past I developed a mount helper [1] which handled the mount of a
> btrfs filesystem: this handler first checks if the filesystem is a
> multivolume devices, if so it waits that all the devices are
> appeared. Finally mount the filesystem.
> 
> > It's not so simple -- such a btrfs device would have THREE states:
> > 
> > 1. not mountable yet (multi-device with not enough disks present)
> > 2. mountable ro / rw-degraded
> > 3. healthy  
> 
> My mount.btrfs could be "programmed" to wait a timeout, then it
> mounts the filesystem as degraded if not all devices are present.
> This is a very simple strategy, but this could be expanded.
> 
> I am inclined to think that the current approach doesn't fit well the
> btrfs requirements.  The roles and responsibilities are spread to too
> much layer (udev, systemd, mount)... I hoped that my helper could be
> adopted in order to concentrate all the responsibility to only one
> binary; this would reduce the interface number with the other
> subsystem (eg systemd, udev).
> 
> For example, it would be possible to implement a sane check that
> prevent to mount a btrfs filesystem if two devices exposes the same
> UUID... 

Ideally, the btrfs wouldn't even appear in /dev until it was assembled
by udev. But apparently that's not the case, and I think this is where
the problems come from. I wish, btrfs would not show up as device nodes
in /dev that the mount command identified as btrfs. Instead, btrfs
would expose (probably through udev) a device node
in /dev/btrfs/fs_identifier when it is ready.

Apparently, the core problem of how to handle degraded btrfs still
remains. Maybe it could be solved by adding more stages of btrfs nodes,
like /dev/btrfs-incomplete (for unusable btrfs), /dev/btrfs-degraded
(for btrfs still missing devices but at least one stripe of btrfs raid
available) and /dev/btrfs as the final stage. That way, a mount process
could wait for a while, and if the device doesn't appear, it tries the
degraded stage instead. If the fs is opened from the degraded dev node
stage, udev (or other processes) that scan for devices should stop
assembling the fs if they still do so.

bcache has a similar approach by hiding an fs within a protective
superblock. Unless bcache is setup, the fs won't show up in /dev, and
that fs won't be visible by other means. Btrfs should do something
similar and only show a single device node if assembled completely. The
component devices would have superblocks ignored by mount, and only the
final node would expose a virtual superblock and the compound device
after it. Of course, this makes things like compound device resizing
more complicated maybe even impossible.

If I'm not totally wrong, I think this is also how zfs exposes its
pools. You need user space tools to make the fs pools visible in the
tree. If zfs is incomplete, there's nothing to mount, and thus no race
condition. But I never tried zfs seriously, so I do not know.

-- 
Regards,
Kai

Replies to list-only preferred.

--
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: Can I see what device was used to mount btrfs?

[Goffredo Baroncelli]

On 2017-05-02 20:49, Adam Borowski wrote:
>> It could be some daemon that waits for btrfs to become complete.  Do we
>> have something?
> Such a daemon would also have to read the chunk tree.

I don't think that a daemon is necessary. As proof of concept, in the past I 
developed a mount helper [1] which handled the mount of a btrfs filesystem:
this handler first checks if the filesystem is a multivolume devices, if so it 
waits that all the devices are appeared. Finally mount the filesystem.

> It's not so simple -- such a btrfs device would have THREE states:
> 
> 1. not mountable yet (multi-device with not enough disks present)
> 2. mountable ro / rw-degraded
> 3. healthy

My mount.btrfs could be "programmed" to wait a timeout, then it mounts the 
filesystem as degraded if not all devices are present. This is a very simple 
strategy, but this could be expanded.

I am inclined to think that the current approach doesn't fit well the btrfs 
requirements.  The roles and responsibilities are spread to too much layer 
(udev, systemd, mount)... I hoped that my helper could be adopted in order to 
concentrate all the responsibility to only one binary; this would reduce the 
interface number with the other subsystem (eg systemd, udev).

For example, it would be possible to implement a sane check that prevent to 
mount a btrfs filesystem if two devices exposes the same UUID... 


BR
G.Baroncelli

[1] See "[RFC][PATCH v2] mount.btrfs helper" thread ( 
https://marc.info/?l=linux-btrfs=141736989508243=2 )



-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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: Can I see what device was used to mount btrfs?

[Adam Borowski]

On Tue, May 02, 2017 at 05:19:34PM +0300, Andrei Borzenkov wrote:
> On Tue, May 2, 2017 at 4:58 PM, Adam Borowski  wrote:
> > On Sun, Apr 30, 2017 at 08:47:43AM +0300, Andrei Borzenkov wrote:
> >> systemd waits for the final device that makes btrfs complete and mounts
> >> it using this device name.
> >
> >> But in /proc/self/mountinfo we actually see another
> >> device name. Due to peculiarities of systemd implementation this device
> >> "does not exist" from systemd PoV.
> >>
> >> Looking at btrfs code I start to suspect that we actually do not know
> >> what device was used to mount it at all.
> >>
> >> So we always show device with the smallest devid, irrespectively of what
> >> device was actually used to mount it.
> >
> > Devices come and go (ok, it's not like you hot-remove disks every day,
> > but...).  Storing the device that started the mount is pointless: btrfs
> > can handle removal fine so such a stored device would point nowhere -- or
> > worse, to some unrelated innocent disk you put in for data recovery (you may
> > have other plans than re-provisioning that raid).
> 
> Yes, I understand all of this, you do not need to convince me. OTOH
> the problem is real - we need to have some way to order btrfs mounts
> during bootup. In the past it was solved by delays. Systemd tries to
> eliminate ad hoc delays ... which is by itself not bad. So what can be
> utilized from btrfs side to implement ordering? We need /something/ to
> wait for. It could be virtual device that represents btrfs RAID and
> have state online/offline (similar to Linux MD).

It's not so simple -- such a btrfs device would have THREE states:

1. not mountable yet (multi-device with not enough disks present)
2. mountable ro / rw-degraded
3. healthy

The distinction between 1 and 2 is important, especially because systemd for
some reason insists on forcing unmount if it thinks the filesystem is in a
bad state (why?!?).  On distributions that follow the traditional remount
scheme (ie, you mount ro during boot, run fsck/whatever (no-op for btrfs),
then remount rw), starting as soon as we're in state 2 would be faster.  It
would also allow automatically going degraded if a timeout is hit[1].

To distinguish between 1 and 2 you need to halfway mount the filesystem, at
least to read the chunk tree (Qu's "why the heck it wasn't merged 2 years
ago" chunk check patch would help).

Naively thinking, it might be tempting to have only two states, varying it
whether the filesystem is already mounted -- currently it's 1+2 vs 3; it
would be: before mount: 1+2 vs 3, after mount: 1 vs 2+3.

But this would lead to breakage in corner cases.

For example: a box has a 3-way raid1 on sda sdb sdc.  Due to a cable not
being firmly seated, power supply or controller having a hiccup, etc,
suddenly sda goes offline.  Btrfs handles that fine, the admin gets worried
and hot-plugs a fourth disk, adding it to the raid.  Reboot.  sda gets up
first, boot goes fine so far, mountall/systemd starts, wants to mount that
filesystem.  sda appears to be fine, systemd reads it and sees there are _3_
disks (as obviously sda doesn't yet know about the fourth).  As sdd was a
random slow crap disk the admin happened to have on the shelf, it's not yet
up.  So systemd sees sda sdb sdc on -- they have all the device IDs it's
looking for, the count is ok, so it assumes all is fine.  It tries to mount,
but btrfs then properly notices there are four disks needed, and because
there was no -odegraded, the mount fails.  Boom.

Thus, there's no real way to know if the mount will succeed beforehand.


> It could be some daemon that waits for btrfs to become complete.  Do we
> have something?

Such a daemon would also have to read the chunk tree.


Meow!

[1]. Not entirely sure if that's a good default -- in one of my boxes, two
disks throw scary errors like UnrecovData BadCRC then after ninetysomething
seconds all goes well, although md (/ is on a 5GB 5-way raid1 md) first goes
degraded then starts autorecovery.  As systemd likes timeouts of 90 seconds,
just a few seconds shy of what this box needs to settle, having systemd and
auto-degrade there would lead to unpaired blocks, which btrfs doesn't yet
repair without being ordered to by hand.

-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.
--
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: Can I see what device was used to mount btrfs?

[Andrei Borzenkov]

On Tue, May 2, 2017 at 4:58 PM, Adam Borowski  wrote:
> On Sun, Apr 30, 2017 at 08:47:43AM +0300, Andrei Borzenkov wrote:
>> I'm chasing issue with btrfs mounts under systemd
>> (https://github.com/systemd/systemd/issues/5781) - to summarize, systemd
>> waits for the final device that makes btrfs complete and mounts it using
>> this device name.
>
> Systemd is wrong here -- its approach can possibly work only on clean mounts;
> if you need to mount degraded it will hang forever.  Even worse, if it's not
> the root filesystem, it will "helpfully" unmount it after you mount manually
> (for root fs, it will _try_ to unmount but that obviously fails, resulting
> in nothing but some CPU wasted on trying to unmount over and over).
>
>> But in /proc/self/mountinfo we actually see another
>> device name. Due to peculiarities of systemd implementation this device
>> "does not exist" from systemd PoV.
>>
>> Looking at btrfs code I start to suspect that we actually do not know
>> what device was used to mount it at all.
>>
>> So we always show device with the smallest devid, irrespectively of what
>> device was actually used to mount it.
>
> Devices come and go (ok, it's not like you hot-remove disks every day,
> but...).  Storing the device that started the mount is pointless: btrfs
> can handle removal fine so such a stored device would point nowhere -- or
> worse, to some unrelated innocent disk you put in for data recovery (you may
> have other plans than re-provisioning that raid).
>

Yes, I understand all of this, you do not need to convince me. OTOH
the problem is real - we need to have some way to order btrfs mounts
during bootup. In the past it was solved by delays. Systemd tries to
eliminate ad hoc delays ... which is by itself not bad. So what can be
utilized from btrfs side to implement ordering? We need /something/ to
wait for. It could be virtual device that represents btrfs RAID and
have state online/offline (similar to Linux MD). It could be some
daemon that waits for btrfs to become complete. Do we have something?
--
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: Can I see what device was used to mount btrfs?

[Adam Borowski]

On Sun, Apr 30, 2017 at 08:47:43AM +0300, Andrei Borzenkov wrote:
> I'm chasing issue with btrfs mounts under systemd
> (https://github.com/systemd/systemd/issues/5781) - to summarize, systemd
> waits for the final device that makes btrfs complete and mounts it using
> this device name.

Systemd is wrong here -- its approach can possibly work only on clean mounts;
if you need to mount degraded it will hang forever.  Even worse, if it's not
the root filesystem, it will "helpfully" unmount it after you mount manually
(for root fs, it will _try_ to unmount but that obviously fails, resulting
in nothing but some CPU wasted on trying to unmount over and over).

> But in /proc/self/mountinfo we actually see another
> device name. Due to peculiarities of systemd implementation this device
> "does not exist" from systemd PoV.
> 
> Looking at btrfs code I start to suspect that we actually do not know
> what device was used to mount it at all.
> 
> So we always show device with the smallest devid, irrespectively of what
> device was actually used to mount it.

Devices come and go (ok, it's not like you hot-remove disks every day,
but...).  Storing the device that started the mount is pointless: btrfs
can handle removal fine so such a stored device would point nowhere -- or
worse, to some unrelated innocent disk you put in for data recovery (you may
have other plans than re-provisioning that raid).


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.
--
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: Can I see what device was used to mount btrfs?

[Anand Jain]

On 04/30/2017 01:47 PM, Andrei Borzenkov wrote:

I'm chasing issue with btrfs mounts under systemd
(https://github.com/systemd/systemd/issues/5781) - to summarize, systemd
waits for the final device that makes btrfs complete and mounts it using
this device name.




But in /proc/self/mountinfo we actually see another
device name.




Due to peculiarities of systemd implementation this device
"does not exist" from systemd PoV.

Looking at btrfs code I start to suspect that we actually do not know
what device was used to mount it at all. I.e.


 Actually it does not matter. right ?


static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
{
...
while (cur_devices) {
head = _devices->devices;
list_for_each_entry(dev, head, dev_list) {
if (dev->missing)
continue;
if (!dev->name)
continue;
if (!first_dev || dev->devid < first_dev->devid)
first_dev = dev;
}
cur_devices = cur_devices->seed;
}

if (first_dev) {
rcu_read_lock();
name = rcu_dereference(first_dev->name);
seq_escape(m, name->str, " \t\n\\");
rcu_read_unlock();
...


So we always show device with the smallest devid, irrespectively of what
device was actually used to mount it.

Am I correct? What I have here is




localhost:~ # ll /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 10 Apr 30 08:03 Storage -> ../../dm-1
localhost:~ # systemctl --no-pager status thin.mount
● thin.mount - /thin
   Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
   Active: active (mounted) since Sun 2017-04-30 08:03:07 MSK; 6min ago
Where: /thin
 What: /dev/dm-0
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 982 ExecMount=/usr/bin/mount /dev/disk/by-label/Storage /thin
-t btrfs (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
   CGroup: /system.slice/thin.mount

Apr 30 08:03:07 localhost systemd[1]: Mounting /thin...
Apr 30 08:03:07 localhost systemd[1]: Mounted /thin.


bur mountinfo shows

localhost:~ # grep /thin /proc/self/mountinfo
96 59 0:63 / /thin rw,relatime shared:47 - btrfs /dev/dm-0
rw,space_cache,subvolid=5,subvol=/

which matches the above algorithm

localhost:~ # btrfs fi show /thin
Label: 'Storage'  uuid: a6f9dd05-460c-418b-83ab-ebdf81f2931a
Total devices 2 FS bytes used 640.00KiB
devid1 size 20.00GiB used 2.01GiB path /dev/mapper/vg01-storage1
devid2 size 10.00GiB used 2.01GiB path /dev/mapper/vg01-storage2

localhost:~ # ll /dev/mapper/
total 0
crw--- 1 root root 10, 236 Apr 30 08:03 control
lrwxrwxrwx 1 root root   7 Apr 30 08:03 vg01-storage1 -> ../dm-0
lrwxrwxrwx 1 root root   7 Apr 30 08:03 vg01-storage2 -> ../dm-1

The original device is presumably stored in kernel somewhere but I do
not know how can I query it?



 Hm, actually we don't know the order in which devices were scanned
 and used for the mount, or it does not matter for the btrfs.

 HTH

Thanks,
Anand




--
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


--
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

Can I see what device was used to mount btrfs?

[Andrei Borzenkov]

I'm chasing issue with btrfs mounts under systemd
(https://github.com/systemd/systemd/issues/5781) - to summarize, systemd
waits for the final device that makes btrfs complete and mounts it using
this device name. But in /proc/self/mountinfo we actually see another
device name. Due to peculiarities of systemd implementation this device
"does not exist" from systemd PoV.

Looking at btrfs code I start to suspect that we actually do not know
what device was used to mount it at all. I.e.

static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
{
...
while (cur_devices) {
head = _devices->devices;
list_for_each_entry(dev, head, dev_list) {
if (dev->missing)
continue;
if (!dev->name)
continue;
if (!first_dev || dev->devid < first_dev->devid)
first_dev = dev;
}
cur_devices = cur_devices->seed;
}

if (first_dev) {
rcu_read_lock();
name = rcu_dereference(first_dev->name);
seq_escape(m, name->str, " \t\n\\");
rcu_read_unlock();
...


So we always show device with the smallest devid, irrespectively of what
device was actually used to mount it.

Am I correct? What I have here is

localhost:~ # ll /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 10 Apr 30 08:03 Storage -> ../../dm-1
localhost:~ # systemctl --no-pager status thin.mount
● thin.mount - /thin
   Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
   Active: active (mounted) since Sun 2017-04-30 08:03:07 MSK; 6min ago
Where: /thin
 What: /dev/dm-0
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 982 ExecMount=/usr/bin/mount /dev/disk/by-label/Storage /thin
-t btrfs (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
   CGroup: /system.slice/thin.mount

Apr 30 08:03:07 localhost systemd[1]: Mounting /thin...
Apr 30 08:03:07 localhost systemd[1]: Mounted /thin.


bur mountinfo shows

localhost:~ # grep /thin /proc/self/mountinfo
96 59 0:63 / /thin rw,relatime shared:47 - btrfs /dev/dm-0
rw,space_cache,subvolid=5,subvol=/

which matches the above algorithm

localhost:~ # btrfs fi show /thin
Label: 'Storage'  uuid: a6f9dd05-460c-418b-83ab-ebdf81f2931a
Total devices 2 FS bytes used 640.00KiB
devid1 size 20.00GiB used 2.01GiB path /dev/mapper/vg01-storage1
devid2 size 10.00GiB used 2.01GiB path /dev/mapper/vg01-storage2

localhost:~ # ll /dev/mapper/
total 0
crw--- 1 root root 10, 236 Apr 30 08:03 control
lrwxrwxrwx 1 root root   7 Apr 30 08:03 vg01-storage1 -> ../dm-0
lrwxrwxrwx 1 root root   7 Apr 30 08:03 vg01-storage2 -> ../dm-1

The original device is presumably stored in kernel somewhere but I do
not know how can I query 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