On 2017-08-03 16:45, Brendan Hide wrote:
On 08/03/2017 09:22 PM, Austin S. Hemmelgarn wrote:
On 2017-08-03 14:29, Christoph Anton Mitterer wrote:
On Thu, 2017-08-03 at 20:08 +0200, waxhead wrote:
There are no higher-level management tools (e.g. RAID
management/monitoring, etc.)...
[snip]
As far as 'higher-level' management tools, you're using your system
wrong if you _need_ them. There is no need for there to be a GUI, or
a web interface, or a DBus interface, or any other such bloat in the
main management tools, they work just fine as is and are mostly on par
with the interfaces provided by LVM, MD, and ZFS (other than the lack
of machine parseable output). I'd also argue that if you can't
reassemble your storage stack by hand without using 'higher-level'
tools, you should not be using that storage stack as you don't
properly understand it.
On the subject of monitoring specifically, part of the issue there is
kernel side, any monitoring system currently needs to be
polling-based, not event-based, and as a result monitoring tends to be
a very system specific affair based on how much overhead you're
willing to tolerate. The limited stuff that does exist is also trivial
to integrate with many pieces of existing monitoring infrastructure
(like Nagios or monit), and therefore the people who care about it a
lot (like me) are either monitoring by hand, or are just using the
tools with their existing infrastructure (for example, I use monit
already on all my systems, so I just make sure to have entries in the
config for that to check error counters and scrub results), so there's
not much in the way of incentive for the concerned parties to reinvent
the wheel.
To counter, I think this is a big problem with btrfs, especially in
terms of user attrition. We don't need "GUI" tools. At all. But we do
need that btrfs is self-sufficient enough that regular users don't get
burnt by what they would view as unexpected behaviour. We have
currently a situation where btrfs is too demanding on inexperienced users.
I feel we need better worst-case behaviours. For example, if *I* have a
btrfs on its second-to-last-available chunk, it means I'm not
micro-managing properly. But users shouldn't have to micro-manage in the
first place. Btrfs (or a management tool) should just know to balance
the least-used chunk and/or delete the lowest-priority snapshot, etc. It
shouldn't cause my services/apps to give diskspace errors when, clearly,
there is free space available.
That's not just an issue with BTRFS, it's an issue with the distros too.
The only one that ships any kind of scheduled regular maintenance as
far as I know is SUSE. We don't need some daemon, or even special
handling in the kernel, we just need to provide people with standard
maintenance tools, and proper advice for monitoring. I've been meaning
to write up some wrappers and a couple of cron files to handle this a
bit better, but just haven't had time. I may look at getting that done
either today or early next week.
The other "high-level" aspect would be along the lines of better
guidance and standardisation for distros on how best to configure btrfs.
This would include guidance/best practices for things like appropriate
subvolume mountpoints and snapshot paths, sensible schedules or logic
(or perhaps even example tools/scripts) for balancing and scrubbing the
filesystem.
There are currently three standards for this:
1. The snapper way, used by at least SUSE and Ubuntu, which IMO ends up
being way too complicated for not much benefit.
2. The traditional filesystem way, used by most other distros, which
doesn't use subvolumes at all.
3. The user choice way, used by stuff like Arch and Gentoo, which pretty
much says the rest of the OS could care less how the filesystems and
subvolumes are organized, as long as things work.
Overall, other than the first one, this is no different than with
regular filesystems.
I don't have all the answers. But I also don't want to have to tell
people they can't adopt it because a) they don't (or never will)
understand it; and b) they're going to resent me for their irresponsibly
losing their own data.
--
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
