Re: wrong values in "df" and "btrfs filesystem df"

[Stephane Chazelas <stephane.chazelas@gmail.com>]

2011-04-12 15:22:57 +0800, Miao Xie:
[...]
> But the algorithm of df command doesn't simulate the above allocation correctly, this
> simulated allocation just allocates the stripes from two disks, and then, these two disks
> have no free space, but the third disk still has 1.2TB free space, df command thinks
> this space can be used to make a new RAID0 block group and ignores it. This is a bug,
> I think.
[...]

Thanks a lot Miao for the detailed explanation. So, the disk
space is not lost, it's just df not reporting the available
space correctly. That's me relieved.

It explains why I'm getting:

# blockdev --getsize64 /dev/sda4
2967698087424
# blockdev --getsize64 /dev/sdb
3000592982016
# blockdev --getsize64 /dev/sdc
3000592982016
# truncate -s 2967698087424 a
# truncate -s 3000592982016 b
# truncate -s 3000592982016 c
# losetup /dev/loop0 ./a
# losetup /dev/loop1 ./b
# losetup /dev/loop2 ./c
# mkfs.btrfs a b c
# btrfs device scan /dev/loop[0-2]
Scanning for Btrfs filesystems in '/dev/loop0'
Scanning for Btrfs filesystems in '/dev/loop1'
Scanning for Btrfs filesystems in '/dev/loop2'
# mount  /dev/loop0 /mnt/1
# df -k /mnt/1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop0           8758675828        56 5859474304   1% /mnt/1
# echo $(((8758675828 - 5859474304)*2**10))
2968782360576

One disk worth of space lost according to df.

While it should have been more something like
$(((3000592982016-2967698087424)*2)) (about 60GB), or about 0
after the quasi-round-robin allocation patch, right?

Best regards,
Stephane