On Thu, 06 Feb 2014 09:38:15 +0200 Brendan Hide <bren...@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
signature.asc
Description: PGP signature
