Re: Unexpected raid1 behaviour

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-12-21 06:44, Andrei Borzenkov wrote:
> On Tue, Dec 19, 2017 at 11:47 PM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2017-12-19 15:41, Tomasz Pala wrote:
>>>
>>> On Tue, Dec 19, 2017 at 12:35:20 -0700, Chris Murphy wrote:
>>>
>>>> with a read only file system. Another reason is the kernel code and
>>>> udev rule for device "readiness" means the volume is not "ready" until
>>>> all member devices are present. And while the volume is not "ready"
>>>> systemd will not even attempt to mount. Solving this requires kernel
>>>> and udev work, or possibly a helper, to wait an appropriate amount of
>>>
>>>
>>> Sth like this? I got such problem a few months ago, my solution was
>>> accepted upstream:
>>>
>>> https://github.com/systemd/systemd/commit/0e8856d25ab71764a279c2377ae593c0f2460d8f
>>>
>>> Rationale is in referred ticket, udev would not support any more btrfs
>>> logic, so unless btrfs handles this itself on kernel level (daemon?),
>>> that is all that can be done.
>>
>> Or maybe systemd can quit trying to treat BTRFS like a volume manager (which
>> it isn't) and just try to mount the requested filesystem with the requested
>> options?
> 
> You can't mount filesystem until sufficient number of devices are
> present and not waiting (at least attempting to wait) for them opens
> you to races on startup. So far systemd position was - it is up to
> filesystem to give it something to wait on. And while apparently
> everyone agrees that current "btrfs device ready" does not fit the
> bill, this is the only thing we have.
No, it isn't.  You can just make the damn mount call with the supplied 
options.  If it succeeds, the volume was ready, if it fails, it wasn't, 
it's that simple, and there's absolutely no reason that systemd can't 
just do that in a loop until it succeeds or a timeout is reached.  That 
isn't any more racy than waiting on them is (waiting on them to be ready 
and then mounting them is a TOCTOU race condition), and it doesn't have 
any of these issues with the volume being completely unusable in a 
degraded state.

Also, it's not 'up to the filesystem', it's 'up to the underlying 
device'.  LUKS, LVM, MD, and everything else that's an actual device 
layer is what systemd waits on.  XFS, ext4, and any other filesystem 
except BTRFS (and possibly ZFS, but I'm not 100% sure about that) 
provides absolutely _NOTHING_ to wait on.  Systemd just chose to handle 
BTRFS like a device layer, and not a filesystem, so we have this crap to 
deal with, as well as the fact that it makes it impossible to manually 
mount a BTRFS volume with missing or failed devices in degraded mode 
under systemd (because it unmounts it damn near instantly because it 
somehow thinks it knows better than the user what the user wants to do).
> 
> This integration issue was so far silently ignored both by btrfs and
> systemd developers. 
It's been ignored by BTRFS devs because there is _nothing_ wrong on this 
side other than the naming choice for the ioctl.  Systemd is _THE ONLY_ 
init system which has this issue, every other one works just fine.

As far as the systemd side, I have no idea why they are ignoring it, 
though I suspect it's the usual spoiled brat mentality that seems to be 
present about everything that people complain about regarding systemd.