What to do about df and btrfs fi df

[Josef Bacik <jbacik@fb.com>]

Hello,

So first of all this is going to get a lot of responses, so straight 
away I'm only going to consider your opinion if I recognize your name 
and think you are a sane person.  This basically means any big 
contributors and we'll make sanity exceptions for cwillu.

These are just broad strokes, let us not get bogged down in the details, 
I just want to come to a consensus on how things _generally_ should be 
portrayed to the user.  We can worry about implementation details once 
we agree on the direction we want to go.

We all know space is a loaded question with btrfs, so I'm just going to 
explain the reasoning of why we chose what we chose originally and then 
offer the direction we should go in.  If you agree say yay, if not 
please provide a very concise alternative suggestion with a very short 
explanation of why it is better than I'm suggesting.  I'm not looking to 
spend a whole lot of time this problem.

Also this isn't going to address b_avail, cause frankly that is some 
fucking voodoo right there, suffice it to say we will just adjust 
b_avail based on how we should represent total and used.

===== ye olde df =====

I don't remember what we did originally, but IIRC we would only show 
used space from the block groups and would show the entire size of the 
fs.  So for example with two 1 tb drives in RAID1 you'd see ENOSPC and 
look at df and it would show total of 2TB and used at 1TB.  Obviously 
not good, so we switched to the mechanism we have today, which is you 
see 2TB for total, you see 2TB for used and you see 0 for available.  We 
just scaled up the used and available based on your raid multiplier.

===== btrfs fi df =====

I made this for me because of ENOSPC issues but of course it's also 
really useful for users.  It is just a dump of the block group 
information and their flags, so really just spits out bytes_used and 
total_bytes and flags.  Because at the block_group/space_info level in 
btrfs we don't care about how much actual space is taken up this number 
is not adjusted for RAID values, and these numbers are reflected in the 
tools output.  So if you have RAID1 you need to mentally multiply the 
Total and Used values by 2 because that is how much actual space is 
being used.

=====  What to do moving forward =====

Flip what both of these do.  Do not multiply for normal df, and multiply 
for btrfs fi df.

===== New and improved df =====

Since this is the lowest common denominator we should just spit out how 
much space is used based on the block groups and then divide the 
remaining space that hasn't been allocated yet by the raid multiplier.

This is going to be kind of tricky once we do per-subvolume RAID levels, 
but this falls under the b_avail voodoo which is just a guess anyway, so 
for this we will probably take the biggest multiplier and use that to 
show how much available space you have.

This way with RAID1 it shows you have 1tb of total space and you've used 
1tb of space.

===== New and improved btrfs fi df =====

Since people using this tool are already going to be better informed and 
since we are already given the block group flags we can go ahead and do 
the raid multiplier in btrfs-progs and spit out the adjusted numbers 
rather than the raw numbers we get from the ioctl.  This will just be a 
progs thing and that way we can possibly add an option to not apply the 
multipliers and just get the raw output.

===== Conclusion =====

Let me know if this is acceptable to everybody.  Remember this is just 
broad strokes, keep your responses short and simple or I simply won't 
read them.  Thanks,

Josef