Re: btrfs device ready purpose

[Duncan <1i5t5.duncan@cox.net>]

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