Re: 64-btrfs.rules and degraded boot

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

On 2016-07-11 17:07, Chris Murphy wrote:
> On Fri, Jul 8, 2016 at 6:24 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>
>> To clarify, I'm not trying to argue against adding support, I'm arguing
>> against it being mandatory.
>
> By "D-Bus support" I did not mean to indicate mandating it, just that
> it would be one possible way to get some very basic state change
> messages to user space tools so we're doing the least amount of wheel
> reinvention as possible.
Minimizing the amount of work would be good, but I would not agree about 
D-Bus doing that.  It's easy to debug socket based IPC, it's not easy to 
debug D-Bus based IPC.  From a development perspective, I'd say we need 
to get something working with sockets first, and then worry about D-Bus 
once we have working infrastructure and abstraction for IPC.
>
>
>>  A filesystem which requires specific system
>> services to be running just for regular maintenance tasks is not a well
>> designed filesystem.  To be entirely honest, I'm not all that happy about
>> the functional dependency on udev to have device discovery, but there's no
>> point in me arguing about that...
>
> Well everything else that came before it is effectively deprecated, so
> there's no going back. The way forward would be to get udev more
> granular state information about a Btrfs volume than 0 and 1.
People still use other options, usually in embedded systems, but options 
do exist and are used.

That said, I couldn't agree more about reporting more info about the 
state of the FS, but I still feel that scanning on device connection is 
not a good thing with the way things are currently designed in the 
kernel, not just the binary state reporting.
>
>>
>> Just thinking aloud, but why not do a daemon that does the actual
>> monitoring, and then provide an interface (at least a UNIX domain socket,
>> and optionally a D-Bus endpoint) that other tools can use to query
>> filesystem status.  LVM already has a similar setup for monitoring DM-RAID
>> volumes, snapshots, and thin storage pools, although it's designed as an
>> event driven tool that does something when specific things happen (for
>> example, possibly auto-extending snapshots when they start to get full).
>
> That would be consistent with mdadm --monitor and dmeventd, but it is
> yet another wheel reinvention at the lower level, which then also
> necessitates higher level things to adapt to that interface. It would
> be neat if there could be some unification and consistency.
>
A consistent external API would be a good thing, but I'm not sure if 
unifying the internal design would be.  Trying to unify handling in an 
external project would make things less reliable, not more reliable, 
because