On 2016-07-07 16:20, Chris Murphy wrote:
On Thu, Jul 7, 2016 at 1:59 PM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
D-Bus support needs to be optional, period. Not everybody uses D-Bus (I
have dozens of systems that get by just fine without it, and know hundreds
of other people who do as well), and even people who do don't always use
every tool needed (on the one system I manage that does have it, the only
things I need it for are Avahi, ConsoleKit, udev, and NetworkManager, and
I'm getting pretty close to the point of getting rid of NM and CK and
re-implementing or forking Avahi). You have to consider the fact that there
are and always will be people who do not install a GUI on their system and
want the absolute minimum of software installed.
That's fine, they can monitor kernel messages directly as their
notification system. I'm concerned with people who don't ever look at
kernel messages, you know, mortal users who have better things to do
with a computer than that. It's important for most anyone to not have
to wait for problems to manifest traumatically.
My point is that they probably need btrfs-progs too. Take me for
example, I don't use some fancy graphical tool to tell me when my disks
are failing, but I don't scrape kernel logs either. I have things set
up to monitor the disks directly (using btrfs-progs in the case of stuff
that can check for), and notify me via e-mail if there's an issue. Not
supporting that use case at all would be like e2fsprogs adding a
dependency on X11 and telling everyone who doesn't want to use X11 to
just go implement their own tools. If that happened, e2fsprogs would
get forked, the commit reverted in that fork, and most of the
non-enterprise distros would probably switch pretty damn quick to the
forked version.
Personally, I don't care what Fedora is doing, or even what GNOME (or any
other DE for that matter, the only reason I use Xfce is because some things
need a GUI (many of them unnecessarily), and that happens to be the DE I
have the fewest complaints about) is doing. The only reason that things
like GNOME Disks and such exist is because they're trying to imitate Windows
and OS X, which is all well and good for a desktop, but is absolute crap for
many server and embedded environments (Microsoft finally realized this, and
Windows Server 2012 added the ability to install without a full desktop,
which actually means that they have _more_ options than a number of Linux
distributions (yes you can rip out the desktop on many distros if you want,
but that takes an insane amount of effort most of the time, not to mention
storage space)).
I'm willing to bet dollars to donuts Xfce fans would love to know if
one of their rootfs mirrors is spewing read errors, while smartd
defers to the drive which says "hey no problems here". GNOME at least
does report certain critical smart errors, but that still leaves
something like 40% of drive failures happening without prior notice.
I'm not saying some specific users don't care, I'm saying that requiring
people to have a specific software stack which may not work for their
use case is a stupid choice for something as low level as this. Yes
people want to know when something failed, but we shouldn't mandate
_how_ they choose in a given system to check this. There need to be
more choices than just a GUI tool and talking directly to the kernel.
Looking at this another way, it is fully possible to implement something
to do this in a DE agnostic manner _without depending on D-BUS_ using
the tools as they are right now. An initial implementation would of
course be inefficient, but until we get notifications _from the kernel_
about FS state, we have to poll regardless, which means that having
D-Bus support would not help (and would probably just make things slower).
Storaged also qualifies as something that _needs_ to be optional, especially
because it appears to require systemd (and it falls into the same category
as D-Bus of 'unnecessary bloat on many systems'). Adding a mandatory
dependency on systemd _will_ split the community and severely piss off quite
a few people (you will likely get some rather nasty looks from a number of
senior kernel developers if you meet them in person).
I just want things to work for users, defined as people who would like
to stop depending on Windows and macOS for both server and desktop
usage. I don't really care about ideological issues outside of that
goal.
Making us hard depend on storaged would not help this goal. It's no
different than the Microsoft and Apple approach of 'our way or not at all'.
To clarify, I'm not trying to argue against adding support, I'm arguing
against it being mandatory. 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...
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). Other than the D-Bus support, I could probably
write a basic piece of software to do this in Python in about a week of
work (most of which would be figuring out the edge cases and making sure
it works on both 2.7 and 3) that would provide similar functionality
(with better configurability too) to that which could easily provide an
interface to query filesystem status.
--
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
