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