On 2016-07-11 17:07, Chris Murphy wrote:
On Fri, Jul 8, 2016 at 6:24 AM, Austin S. Hemmelgarn
<ahferro...@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
--
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
