Re: btrfs device ready purpose

[Duncan]

Chris Murphy posted on Sat, 22 Jul 2017 14:35:25 -0600 as excerpted:

> If we go back even further in time, what I'm trying to avoid is the
> problem with DE's where the user connects a two device Btrfs, and then
> they want to eject it. The DE is already confused because behind the
> scenes it has actually mounted each device to two different mount
> points, which Btrfs allows (it's one file system, on two mount points).
> That's confusing, but not a big problem. The big problem happens when
> the user wants to stop using that file system. So they eject one of the
> two appearing devices (which should of course only be one with Btrfs)
> and behind the scenes udisksd umounts just one of the mountpoints and
> then appears to delete that device node, which in effect makes the still
> mounted file system degraded, and results in corruption.
> 
> Btrfs fixes this up on the next mount of both devices. But it's just
> asking for trouble.
> 
> Output of this behavior here:
> https://bugs.freedesktop.org/show_bug.cgi?id=87277#c3

Ugh.  Yet another reason for me to be glad I've neutered that behavior on 
my installation of my DE of choice.[1]

But the main problem would appear to be the still lacking in the after 
all still not yet fully stable and under heavy development btrfs, concept 
of device tracking and disappearance/reappearance handling.  Without 
that, all sorts of would-be expected multi-device behavior is missing.

As it happens, the device tracking concept/feature was necessary for the 
now long back-burnered hot-spare feature, so got pulled into that patch 
set, along with the per-chunk device availability check that allows 
proper degraded writable-mount raid1, etc.

Of course the latter got dusted off and now appears close to merge (yay!, 
double-yay since all my btrfs are raid1 or dup, here, and it could come 
in quite handy if an ssd starts acting up!), but the rest of that patch 
set, AFAIK, remains back-burnered with no preliminary target merge kernel 
set.

Perhaps the next bit of it we need to dust off and get ready to merge is 
the real dynamic device detection stuff.  Of course that'll make the hot-
spares patch set smaller and easier to merge in the end, but it should 
also make fixing a whole family of issues related to the fact that btrfs 
really doesn't detect device disappearance either go away directly, or 
make the patches much more trivial than they would be otherwise, since we 
simply don't have the functionality we need for it, yet.

---
[1] My DE:  A "lite" version of kde/plasma, without the semantic-desktop 
stuff and without the device detection, etc.  It still build/link/run 
depends on solid for what would be device detection/activation, but that 
in turn run-time depends on udisks.  But fortunately, udisks is only a 
run-time dep, with the executable actually a script after all so it's not 
going to be linked in, so as a gentooer I have a few alternatives 
including the one I've taken, providing a "null-package" udisks package 
that installs nothing and depends on nothing, so devices don't get auto-
mounted, which makes me happy, but I also don't have to worry about all 
the stuff udisks would otherwise pull in in its turn.  Not like they'd be 
automountable anyway given that I don't have policykit, etc, installed, 
but this way I don't have to worry about the additional deps, either.

I get a few complaints in the log when plasma starts up, but other than 
that, it behaves as I want -- no mounts unless I specifically ask for 
them either as root (usually via sudo), or with the appropriate fstab 
options.  To let it behave otherwise and do automatic mounts without that 
sort of strict control is practically /begging/ for unexpected/undefined 
behavior, some of which, no surprise given the problems MS has had with 
this whole idea that we should have learned from, turns out to be data-
loss and/or security risky, as it is here.

-- 
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: btrfs device ready purpose

[Chris Murphy]

On Sat, Jul 22, 2017 at 1:58 PM, Adam Borowski  wrote:
> On Sat, Jul 22, 2017 at 06:15:58PM +, Hugo Mills wrote:
>> On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote:
>> > I just did an additional test that's pretty icky behavior.
>> >
>> > 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready`
>> > exits with 0 as expected. Physically remove both USB devices.
>> > Reconnect one device. `btrfs device ready` still exits 0. That's
>> > definitely not good. (If I leave that one device connected and reboot,
>> > `btrfs device ready` exits 1).
>>
>>In a slightly less-specific way, this has been a problem pretty
>> much since the inception of the FS. It's not possible to do the
>> reverse of the "scan" operation on a device -- that is, invalidate/
>> remove the device's record in the kernel. So, as you've discovered
>> here, if you have a device which is removed (overwritten, unplugged),
>> the kernel still thinks it's a part of the FS.
>
> Alas, this needs to be fixed.  The reproducers I posted last week give data
> corruption in case a device that was once a part of the FS is reconnected.
> It doesn't matter what it contains now -- be it another part of the FS or
> something totally unrelated, as far as the device node (/dev/loop0,
> /dev/sda1, etc) is reused, degraded mounts get confused.
>
> It wasn't urgent before as degraded mounts were broken before Qu's chunk
> check patch (that's not even merged yet) -- but once running degraded is
> not an emergency, there'll be folks doing so for an extended time.
>
>>It's something I recall being talked about a bit, some years ago. I
>> don't recall now why it was going to be useful, though. I think you
>> have a good use-case for such a new ioctl (or extension to the
>> SCAN_DEV ioctl) now, though.
>
> Such an ioctl would be inherently racey.  Even current udev code is --
> mounting right after losetup often fails, sometimes you even need to sleep
> longer than 1 second.  With the above in mind, I see no way other than
> invalidating and re-checking all known devices at mount time.


If we go back even further in time, what I'm trying to avoid is the
problem with DE's where the user connects a two device Btrfs, and then
they want to eject it. The DE is already confused because behind the
scenes it has actually mounted each device to two different mount
points, which Btrfs allows (it's one file system, on two mount
points). That's confusing, but not a big problem. The big problem
happens when the user wants to stop using that file system. So they
eject one of the two appearing devices (which should of course only be
one with Btrfs) and behind the scenes udisksd umounts just one of the
mountpoints and then appears to delete that device node, which in
effect makes the still mounted file system degraded, and results in
corruption.

Btrfs fixes this up on the next mount of both devices. But it's just
asking for trouble.

Output of this behavior here:
https://bugs.freedesktop.org/show_bug.cgi?id=87277#c3

So then I started to look at whether it's possible to easily determine
in advance if a Btrfs file system is single or multiple device, and
let udisksd have a policy where it will just ignore multiple device
Btrfs entirely - just don't support it until the guts of all this
infrastructure gets better.

'strace btrfs filesystem show' curiously shows BTRFS_IOC_FS_INFO is
only called for single device Btrfs. There is seemingly a much more
esoteric, btrfs-progs only method for getting information for multiple
device Btrfs volumes. And therefore I'm not certain if
BTRFS_IOC_FS_INFO supports multiple device Btrfs, and would return
num_devices so that it's possible to know whether to ignore devices
for a multiple device Btrfs volume.

*sigh*


Chris Murphy



-- 
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: btrfs device ready purpose

[Adam Borowski]

On Sat, Jul 22, 2017 at 06:15:58PM +, Hugo Mills wrote:
> On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote:
> > I just did an additional test that's pretty icky behavior.
> > 
> > 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready`
> > exits with 0 as expected. Physically remove both USB devices.
> > Reconnect one device. `btrfs device ready` still exits 0. That's
> > definitely not good. (If I leave that one device connected and reboot,
> > `btrfs device ready` exits 1).
> 
>In a slightly less-specific way, this has been a problem pretty
> much since the inception of the FS. It's not possible to do the
> reverse of the "scan" operation on a device -- that is, invalidate/
> remove the device's record in the kernel. So, as you've discovered
> here, if you have a device which is removed (overwritten, unplugged),
> the kernel still thinks it's a part of the FS.

Alas, this needs to be fixed.  The reproducers I posted last week give data
corruption in case a device that was once a part of the FS is reconnected. 
It doesn't matter what it contains now -- be it another part of the FS or
something totally unrelated, as far as the device node (/dev/loop0,
/dev/sda1, etc) is reused, degraded mounts get confused.

It wasn't urgent before as degraded mounts were broken before Qu's chunk
check patch (that's not even merged yet) -- but once running degraded is
not an emergency, there'll be folks doing so for an extended time.

>It's something I recall being talked about a bit, some years ago. I
> don't recall now why it was going to be useful, though. I think you
> have a good use-case for such a new ioctl (or extension to the
> SCAN_DEV ioctl) now, though.

Such an ioctl would be inherently racey.  Even current udev code is --
mounting right after losetup often fails, sometimes you even need to sleep
longer than 1 second.  With the above in mind, I see no way other than
invalidating and re-checking all known devices at mount time.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.
--
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: btrfs device ready purpose

[Hugo Mills]

On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote:
> I just did an additional test that's pretty icky behavior.
> 
> 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready`
> exits with 0 as expected. Physically remove both USB devices.
> Reconnect one device. `btrfs device ready` still exits 0. That's
> definitely not good. (If I leave that one device connected and reboot,
> `btrfs device ready` exits 1).

   In a slightly less-specific way, this has been a problem pretty
much since the inception of the FS. It's not possible to do the
reverse of the "scan" operation on a device -- that is, invalidate/
remove the device's record in the kernel. So, as you've discovered
here, if you have a device which is removed (overwritten, unplugged),
the kernel still thinks it's a part of the FS.

   It's something I recall being talked about a bit, some years ago. I
don't recall now why it was going to be useful, though. I think you
have a good use-case for such a new ioctl (or extension to the
SCAN_DEV ioctl) now, though.

   Hugo.

-- 
Hugo Mills | UNIX: Italian pen maker
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature

Re: btrfs device ready purpose

[Chris Murphy]

I just did an additional test that's pretty icky behavior.

2x HDD device Btrfs volume. Add both devices and `btrfs devices ready`
exits with 0 as expected. Physically remove both USB devices.
Reconnect one device. `btrfs device ready` still exits 0. That's
definitely not good. (If I leave that one device connected and reboot,
`btrfs device ready` exits 1).


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: btrfs device ready purpose

[Chris Murphy]

On Fri, Jul 21, 2017 at 11:55 PM, Andrei Borzenkov  wrote:
> 21.07.2017 17:36, Chris Murphy пишет:
>>>
>>> The command is just a simple wrapper around the DEVICES_READY ioctl, but
>>> now that systemd has it's own wrapper tool, there are probably no users
>>> of that subcommand in 'btrfs' tool itself. We can enhance the
>>> documentation to state the expected purpose and that normal users can
>>> ignore it.
>>
>> What is the expected purpose? It flat out does not seem to work at
>> all. It doesn't wait when devices are missing, as the man description
>> says.
>
> That's man page that is misleading. The intent was to let caller of
> "btrfs device ready" to know when it has to wait.
>
>> And echo ? returns a 0 instead of 1. I'd expect the exit code is
>> 0 to mean "yes all devices are ready", and exit code 1 "some devices
>> not ready". But right now, I get the same result no matter what.
>>
>
> That's not what I observe.
>
> linux-gtrk:~ # btrfs device ready /dev/sdb
> linux-gtrk:~ # echo $?
> 1
> linux-gtrk:~ # btrfs-debug-tree /dev/sdb
> btrfs-progs v4.5.3+20160729
> warning, device 2 is missing
> ...
>
> But if you call "btrfs device ready" AFTER kernel has already seen (or
> decided about) all devices, then it returns 0. Basically, this is not
> "filesystem ready" but "does kernel know about all devices for this
> filesystem".

OK! Super! This is the critical bit of behavior. My test is flawed.

The multiple device volume was visible to the kernel, and then I
merely deactivated the LV. The kernel had seen it, and isn't "missing"
it at least in terms of 'btrfs device ready' whereas 'btrfs fi show'
does report it as missing but is also using different ioctls. Even if
I use 'btrfs device scan' a subsequent 'btrfs device ready' exits 0.
But if I set skip activation 'lvchange -ky' and reboot, 'btrfs device
ready' on the non-missing device does result in an exit code of 1.


> Please do not confuse independent things. "btrfs device ready" simply
> tells caller whether all devices have been seen by kernel. This is poor
> man's solution for "can I mount it". What caller does with this
> information is outside of scope of btrfs.

Got it. Thanks.


>
>> I think it'd be better to return a code.
>> 0: is complete, degraded not required
>> 1: is incomplete, degraded should mount it
>> 2: is incomplete, degraded won't mount it
>>
>
> There is no way systemd can make use of this information using current
> static unit dependencies. Really, this topic came up more than once
> (including by you as well). systemd does not have adequate ways to
> represent multi-device objects (this goes beyond btrfs, Linux MD is good
> example). Sometimes it is possible to workaround it (Linux MD again).
> But at the end, systemd needs to offer framework where btrfs et al can
> plug in by providing status. Until this happens, discussion on this list
> is pointless.

Understood.


-- 
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: btrfs device ready purpose

[Andrei Borzenkov]

21.07.2017 17:36, Chris Murphy пишет:
>>
>> The command is just a simple wrapper around the DEVICES_READY ioctl, but
>> now that systemd has it's own wrapper tool, there are probably no users
>> of that subcommand in 'btrfs' tool itself. We can enhance the
>> documentation to state the expected purpose and that normal users can
>> ignore it.
> 
> What is the expected purpose? It flat out does not seem to work at
> all. It doesn't wait when devices are missing, as the man description
> says.

That's man page that is misleading. The intent was to let caller of
"btrfs device ready" to know when it has to wait.

> And echo ? returns a 0 instead of 1. I'd expect the exit code is
> 0 to mean "yes all devices are ready", and exit code 1 "some devices
> not ready". But right now, I get the same result no matter what.
> 

That's not what I observe.

linux-gtrk:~ # btrfs device ready /dev/sdb
linux-gtrk:~ # echo $?
1
linux-gtrk:~ # btrfs-debug-tree /dev/sdb
btrfs-progs v4.5.3+20160729
warning, device 2 is missing
...

But if you call "btrfs device ready" AFTER kernel has already seen (or
decided about) all devices, then it returns 0. Basically, this is not
"filesystem ready" but "does kernel know about all devices for this
filesystem".

> So it seems to me it needs to be fixed in user space or it just needs
> to be removed.
> 
> Where this stems from, is this 'help wanted' issue
> https://github.com/storaged-project/libblockdev/issues/244
> 
> The gist is that libblockdev needs to know whether a device can be
> mounted successfully without -o degraded, and that's basically what
> BTRFS_IOC_DEVICES_READY does. But at least in startup, the udev usage
> of this ioctl causes a hang. Literally systemd just sits there and
> will not try to mount such a volume, and it waits indefinitely, which
> is itself suboptimal.

Please do not confuse independent things. "btrfs device ready" simply
tells caller whether all devices have been seen by kernel. This is poor
man's solution for "can I mount it". What caller does with this
information is outside of scope of btrfs.

> I think it'd be better to return a code.
> 0: is complete, degraded not required
> 1: is incomplete, degraded should mount it
> 2: is incomplete, degraded won't mount it
> 

There is no way systemd can make use of this information using current
static unit dependencies. Really, this topic came up more than once
(including by you as well). systemd does not have adequate ways to
represent multi-device objects (this goes beyond btrfs, Linux MD is good
example). Sometimes it is possible to workaround it (Linux MD again).
But at the end, systemd needs to offer framework where btrfs et al can
plug in by providing status. Until this happens, discussion on this list
is pointless.
--
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: btrfs device ready purpose

[Chris Murphy]

On Mon, Jul 17, 2017 at 9:54 AM, David Sterba  wrote:
> On Fri, Jul 07, 2017 at 11:40:04AM -0600, Chris Murphy wrote:
>> On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov  
>> wrote:
>> > 07.07.2017 19:42, Chris Murphy пишет:
>> >> I'm digging through piles of list emails and not really finding an
>> >> answer to this. Maybe it's Friday and I'm just confused...
>> >>
>> >>
>> >> [root@f26s ~]# btrfs device ready /dev/sda1
>> >> [root@f26s ~]# echo $?
>> >> 0
>> >> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1
>> >> [root@f26s ~]# echo $?
>> >> 0
>> >>
>> >>
>> >> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' 
>> >> finds it.
>> >> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the
>> >> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not
>> >> 2 and says a device is missing.
>> >>
>> >> And yet the ready command completes and the exit code is the same, and
>> >> I just don't understand the purpose of this command. The man page says
>> >> "wait" but I don't see any waiting, so at the very least we probably
>> >> need to come up with a more descriptive man page description.
>> >>
>> >
>> > Here on Ubuntu 16.04.2 man page says
>> >
>> >ready 
>> >Check device to see if it has all of it’s devices in cache
>> > for mounting.
>>
>> 4.11 man page says for 'btrfs device ready'
>> Wait until all devices of a multiple-device filesystem are scanned and
>> registered within the kernel module.
>>
>> Not sure when it was updated.
>>
>>
>> >
>> > Nothing about "wait".
>> >
>> > btrfs device ready is only useful during startup. The only check it does
>> > - whether kernel knows about all devices or not. It is really intended
>> > to be used from udev rule to delay attempt to mount filesystem until all
>> > devices have been seen. And it is only useful with systemd as it is the
>> > only program that actually pays attention to it.
>>
>> OK that make sense. I'm just not used to the convention where a user
>> space tool does literally nothing for the user, and also has a man
>> page entry as if it is for users. And I get that developers are users
>> too, it just seems like an odd convention but whatever.
>
> The command is just a simple wrapper around the DEVICES_READY ioctl, but
> now that systemd has it's own wrapper tool, there are probably no users
> of that subcommand in 'btrfs' tool itself. We can enhance the
> documentation to state the expected purpose and that normal users can
> ignore it.

What is the expected purpose? It flat out does not seem to work at
all. It doesn't wait when devices are missing, as the man description
says. And echo ? returns a 0 instead of 1. I'd expect the exit code is
0 to mean "yes all devices are ready", and exit code 1 "some devices
not ready". But right now, I get the same result no matter what.

So it seems to me it needs to be fixed in user space or it just needs
to be removed.

Where this stems from, is this 'help wanted' issue
https://github.com/storaged-project/libblockdev/issues/244

The gist is that libblockdev needs to know whether a device can be
mounted successfully without -o degraded, and that's basically what
BTRFS_IOC_DEVICES_READY does. But at least in startup, the udev usage
of this ioctl causes a hang. Literally systemd just sits there and
will not try to mount such a volume, and it waits indefinitely, which
is itself suboptimal. I think it'd be better to return a code.
0: is complete, degraded not required
1: is incomplete, degraded should mount it
2: is incomplete, degraded won't mount it

Something like that.



-- 
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: btrfs device ready purpose

[David Sterba]

On Fri, Jul 07, 2017 at 11:40:04AM -0600, Chris Murphy wrote:
> On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov  wrote:
> > 07.07.2017 19:42, Chris Murphy пишет:
> >> I'm digging through piles of list emails and not really finding an
> >> answer to this. Maybe it's Friday and I'm just confused...
> >>
> >>
> >> [root@f26s ~]# btrfs device ready /dev/sda1
> >> [root@f26s ~]# echo $?
> >> 0
> >> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1
> >> [root@f26s ~]# echo $?
> >> 0
> >>
> >>
> >> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' 
> >> finds it.
> >> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the
> >> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not
> >> 2 and says a device is missing.
> >>
> >> And yet the ready command completes and the exit code is the same, and
> >> I just don't understand the purpose of this command. The man page says
> >> "wait" but I don't see any waiting, so at the very least we probably
> >> need to come up with a more descriptive man page description.
> >>
> >
> > Here on Ubuntu 16.04.2 man page says
> >
> >ready 
> >Check device to see if it has all of it’s devices in cache
> > for mounting.
> 
> 4.11 man page says for 'btrfs device ready'
> Wait until all devices of a multiple-device filesystem are scanned and
> registered within the kernel module.
> 
> Not sure when it was updated.
> 
> 
> >
> > Nothing about "wait".
> >
> > btrfs device ready is only useful during startup. The only check it does
> > - whether kernel knows about all devices or not. It is really intended
> > to be used from udev rule to delay attempt to mount filesystem until all
> > devices have been seen. And it is only useful with systemd as it is the
> > only program that actually pays attention to it.
> 
> OK that make sense. I'm just not used to the convention where a user
> space tool does literally nothing for the user, and also has a man
> page entry as if it is for users. And I get that developers are users
> too, it just seems like an odd convention but whatever.

The command is just a simple wrapper around the DEVICES_READY ioctl, but
now that systemd has it's own wrapper tool, there are probably no users
of that subcommand in 'btrfs' tool itself. We can enhance the
documentation to state the expected purpose and that normal users can
ignore 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: btrfs device ready purpose

[Austin S. Hemmelgarn]

On 2017-07-07 13:40, Chris Murphy wrote:

On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov  wrote:

07.07.2017 19:42, Chris Murphy пишет:

I'm digging through piles of list emails and not really finding an
answer to this. Maybe it's Friday and I'm just confused...


[root@f26s ~]# btrfs device ready /dev/sda1
[root@f26s ~]# echo $?
0
[root@f26s ~]# btrfs device ready /dev/mapper/vg-1
[root@f26s ~]# echo $?
0


/dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds it.
/dev/mapper/vg-1 is one member of a two device Btrfs volume, the
missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not
2 and says a device is missing.

And yet the ready command completes and the exit code is the same, and
I just don't understand the purpose of this command. The man page says
"wait" but I don't see any waiting, so at the very least we probably
need to come up with a more descriptive man page description.



Here on Ubuntu 16.04.2 man page says

ready 
Check device to see if it has all of it’s devices in cache
for mounting.


4.11 man page says for 'btrfs device ready'
Wait until all devices of a multiple-device filesystem are scanned and
registered within the kernel module.

Not sure when it was updated.




Nothing about "wait".

btrfs device ready is only useful during startup. The only check it does
- whether kernel knows about all devices or not. It is really intended
to be used from udev rule to delay attempt to mount filesystem until all
devices have been seen. And it is only useful with systemd as it is the
only program that actually pays attention to it.


OK that make sense. I'm just not used to the convention where a user
space tool does literally nothing for the user, and also has a man
page entry as if it is for users. And I get that developers are users
too, it just seems like an odd convention but whatever.

TBH, it's not even entirely useful during startup.  Even if all the 
devices are supposedly there, the filesystem may still not mount because 
of any number of other issues, the inherent TOCTOU race not 
withstanding, and even if all the devices aren't there, the filesystem 
may still mount depending on what options you pass.

--
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: btrfs device ready purpose

[Chris Murphy]

On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov  wrote:
> 07.07.2017 19:42, Chris Murphy пишет:
>> I'm digging through piles of list emails and not really finding an
>> answer to this. Maybe it's Friday and I'm just confused...
>>
>>
>> [root@f26s ~]# btrfs device ready /dev/sda1
>> [root@f26s ~]# echo $?
>> 0
>> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1
>> [root@f26s ~]# echo $?
>> 0
>>
>>
>> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds 
>> it.
>> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the
>> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not
>> 2 and says a device is missing.
>>
>> And yet the ready command completes and the exit code is the same, and
>> I just don't understand the purpose of this command. The man page says
>> "wait" but I don't see any waiting, so at the very least we probably
>> need to come up with a more descriptive man page description.
>>
>
> Here on Ubuntu 16.04.2 man page says
>
>ready 
>Check device to see if it has all of it’s devices in cache
> for mounting.

4.11 man page says for 'btrfs device ready'
Wait until all devices of a multiple-device filesystem are scanned and
registered within the kernel module.

Not sure when it was updated.


>
> Nothing about "wait".
>
> btrfs device ready is only useful during startup. The only check it does
> - whether kernel knows about all devices or not. It is really intended
> to be used from udev rule to delay attempt to mount filesystem until all
> devices have been seen. And it is only useful with systemd as it is the
> only program that actually pays attention to it.

OK that make sense. I'm just not used to the convention where a user
space tool does literally nothing for the user, and also has a man
page entry as if it is for users. And I get that developers are users
too, it just seems like an odd convention but whatever.

-- 
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: btrfs device ready purpose

[Andrei Borzenkov]

07.07.2017 19:42, Chris Murphy пишет:
> I'm digging through piles of list emails and not really finding an
> answer to this. Maybe it's Friday and I'm just confused...
> 
> 
> [root@f26s ~]# btrfs device ready /dev/sda1
> [root@f26s ~]# echo $?
> 0
> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1
> [root@f26s ~]# echo $?
> 0
> 
> 
> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds 
> it.
> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the
> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not
> 2 and says a device is missing.
> 
> And yet the ready command completes and the exit code is the same, and
> I just don't understand the purpose of this command. The man page says
> "wait" but I don't see any waiting, so at the very least we probably
> need to come up with a more descriptive man page description.
> 

Here on Ubuntu 16.04.2 man page says

   ready 
   Check device to see if it has all of it’s devices in cache
for mounting.

Nothing about "wait".

btrfs device ready is only useful during startup. The only check it does
- whether kernel knows about all devices or not. It is really intended
to be used from udev rule to delay attempt to mount filesystem until all
devices have been seen. And it is only useful with systemd as it is the
only program that actually pays attention to 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

btrfs device ready purpose

[Chris Murphy]

I'm digging through piles of list emails and not really finding an
answer to this. Maybe it's Friday and I'm just confused...


[root@f26s ~]# btrfs device ready /dev/sda1
[root@f26s ~]# echo $?
0
[root@f26s ~]# btrfs device ready /dev/mapper/vg-1
[root@f26s ~]# echo $?
0


/dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds it.
/dev/mapper/vg-1 is one member of a two device Btrfs volume, the
missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not
2 and says a device is missing.

And yet the ready command completes and the exit code is the same, and
I just don't understand the purpose of this command. The man page says
"wait" but I don't see any waiting, so at the very least we probably
need to come up with a more descriptive man page description.

Thanks.


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