I'd guess normal df (not btrfs filesystem df) and doing the math in his
head will be the simplest for him, as it is for me.
But it's worth noting that normal df with math in your head isn't
/always/ going to be the answer, as things start getting rather more
complex as soon as different sized devices get thrown into the mix, or
raid1/10 on an /odd/ number of devices (tho there the math simply gets
a
bit more complex since it's no longer integers), let alone the case of
differing data/metadata allocation mode, without even considering the
case of subvolumes having different modes, since I don't think that's
implemented yet.
I think you've hit the nail on the head here Duncan. You're absolutely
right that given my simple setup (even number of devices, all the same
size, on raid10) it's trivial to do the math in my head. However I don't
think this approach really scales as well as btrfs is intended to scale
(up to big numbers, mixed device sizes, mixed raid levels etc etc).
Obviously the implementation of a sane df output for all this stuff is
non-trivial, but in the long run I don't think expecting the user to
figure it out is the best approach. I speak here as an interested
sysadmin who quite enjoys rough edges... but for a lot of users the
primary thing they want to know about their storage is "how much space
do I have left".
The documentation does do a good job of pointing out the problems and
explaining why free space is a tricky concept. But does "tricky"
/really/ mean "impossible", or is it just "this is a nice to have thing
that we'll figure out once the core filesystem functions are stable"?
Cheers,
---tim
--
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
