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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
