Re: Provide a better free space estimate on RAID1

[Roman Mamedov <rm@romanrm.net>]

[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]

On Thu, 06 Feb 2014 09:38:15 +0200
Brendan Hide <brendan@swiftspirit.co.za> wrote:

> This is a known issue: 
> https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F
> Btrfs is still considered experimental 

It's long overdue to start tackling these snags and 'stop hiding behind the
experimental flag' [1], which is also no longer present as of 3.13.

[1] http://www.spinics.net/lists/linux-btrfs/msg30396.html

> this is just one of those caveats we've learned to adjust to.

Sure, but it's hard to argue this particular behavior is clearly broken from
the user perspective, even if it's "broken by design", and there are a number
of very "smart" and "future-proof" reasons to keep it broken today.

Personally I tired of trying to keep in mind which partitions are btrfs raid1,
and mentally divide the displayed free space by two for those. That's what
computers are for, to keep track of such things.

> The change could work well for now and I'm sure it has been considered. 
> I guess the biggest end-user issue is that you can, at a whim, change 
> the model for new blocks - raid0/5/6,single etc and your value from 5 
> minutes ago is far out from your new value without having written 
> anything or taken up any space. Not a show-stopper problem, really.

Changing the allocation profile for new blocks is a serious change you don't do
accidentally, it's about the same importance level as e.g. resizing the
filesystem. And no one is really surprised when the 'df' result changes after
an FS resize.

> The biggest dev issue is that future features will break this behaviour, 

That could be years away.

> such as the "per-subvolume RAID profiles" you mentioned. It is difficult 
> to motivate including code (for which there's a known workaround) where 
> we know it will be obsoleted.

There's not a lot of code to include (as my 3-line patch demonstrates), it
could just as easily be removed when it's obsolete. But I did not have any
high hopes of defeating the "broken by design" philosophy, that's why I didn't
submit it as a real patch for inclusion but rather just as a helpful hint for
people to add to their own kernels if they want this change to happen.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]