Re: [PATCH v2 1/3] Btrfs: get more accurate output in df command.

[Robert White <rwhite@pobox.com>]

On 12/14/2014 10:06 PM, Robert White wrote:
> On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
>> Anyone have some suggestion about it?
> (... strong advocacy for raw numbers...)

Concise Example to attempt to be clearer:

/dev/sda == 1TiB
/dev/sdb == 2TiB
/dev/sdc == 3TiB
/dev/sdd == 3TiB

mkfs.btrfs /dev/sd{a..d} -d raid0
mount /dev/sda /mnt

Now compare ::

#!/bin/bash
dd if=/dev/urandom of=/mnt/example bs=1G

vs

#!/bin/bash
typeset -i counter
for ((counter=0;;counter++)); do
dd if=/dev/urandom of=/mnt/example$conter bs=44 count=1
done

vs

#!/bin/bash
typeset -i counter
for ((counter=0;;counter++)); do
dd if=/dev/urandom of=/mnt/example$conter bs=44 count=1
done &
dd if=/dev/urandom of=/mnt/example bs=1G

Now repeat the above 3 models for
mkfs.btrfs /dev/sd{a..d} -d raid5


......

As you watch these six examples evolve you can ponder the ultimate 
futility of doing adaptive prediction within statfs().

Then go back and change the metadata from the default of RAID1 to RAID5 
or RAID6 or RAID10.

Then go back and try

mkfs.btrfs /dev/sd{a..d} -d raid10

then balance when the big file runs out of space, then resume the big 
file with oflag=append

......

Unlike _all_ our predecessors, we are active at both the semantic file 
storage level _and_ the physical media management level.

None of the prior filesystems match this new ground exactly.

The only real option is to expose the raw numbers and then tell people 
the corner cases.

Absolutely unavailable blocks, such as the massive waste of 5TiB in the 
above sized media if raid10 were selected for both data and metadata 
would be subtracted from size if and only if it's _impossible_ for it to 
be accessed by this sort of restriction. But even in this case, the 
correct answer for size is 4TiB because that exactly answers "how big is 
this filesystem".

It might be worth having a "dev_item.bytes_excluded" or unusable or 
whatever to account for the difference between total_bytes and 
bytes_used and the implicit bytes available. This would account for the 
0,1,2,2 TiB that a raid10 of the example sizes could never reach in the 
current geometry. I'm betting that this sort of number also shows up as 
some number of sectors in any filesystem that has an odd tidbit of size 
up at the top where no structure is ever gong to fit. That's just a 
feature of the way disks use GB instead of GiB and msdos style 
partitions love the number 63.

So resize sets the size. Geometry limitations may reduce the effective 
size by some, or a _lot_, but then the used-vs-available should _not_ 
try to correct for whatever geometry is in use. Even when it might be 
simple because if it does it well in the simple cases like 
raid10/raid10, it would have to botch it up on the hard cases.