At 2018-01-04 19:41:27, "Richard W.M. Jones" <rjones@redhat.com> wrote:
>On Thu, Jan 04, 2018 at 12:58:40PM +0800, Chen Fan wrote:
>[In guest]
>> python -c 'import os; s = os.statvfs ("/"); print s'
>> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149,
>> f_bfree=4802342, f_bavail=4802342, f_files=23556096,
>> f_ffree=23435372, f_favail=23435372, f_flag=4096, f_namemax=255)
>> 
>> python -c 'import os; s = os.statvfs ("/boot"); print s'
>> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147,
>> f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626,
>> f_favail=511626, f_flag=4096, f_namemax=255)
>
>[From the host via libguestfs]
>> # guestfish --ro -d rpm-build-for-7.2 -i statvfs /
>> 
>> bsize: 4096
>> frsize: 4096
>> blocks: 5886149
>> bfree: 4810534
>> bavail: 4810534
>> files: 23556096
>> ffree: 23435372
>> favail: 23435372
>> fsid: 64513
>> flag: 4097
>> namemax: 255
>> 
>> # sudo guestfish --ro -d rpm-build-for-7.2 -i statvfs /boot
>> bsize: 4096
>> frsize: 4096
>> blocks: 127147
>> bfree: 100215
>> bavail: 100215
>> files: 512000
>> ffree: 511626
>> favail: 511626
>> fsid: 2049
>> flag: 4097
>> namemax: 255
>
>Was the guest quiescent and fully sync()d before you ran the python
>commands?

yes, almost the guest is quiescent, and after invoke sync(), the results have no different.

>
>In any case all that libguestfs is doing is executing the
>statvfs(2) system call on a copy of the disk:
>
>  https://github.com/libguestfs/libguestfs/blob/e6e23c4d77ee15779f833fd4fbe6c574940e85a4/daemon/statvfs.c#L52
>
>So if there's any difference then it's something to do with the guest
>kernel vs the host kernel calculations.

I saw that when doing virt-df, virt-df created a  temporary VM with the host kernel, so I
recreate a temporary QEMU VM with command line: 
/usr/libexec/qemu-kvm -cpu host -m 1024 -nographic -kernel /var/tmp/.guestfs-0/appliance.d/kernel -initrd /var/tmp/.guestfs-0/appliance.d/initrd -append "console=ttyS0 root=/dev/vda guestfs_rescue=1" -device virtio-blk-pci,drive=disk0 -drive file=/var/tmp/.guestfs-0/appliance.d/root,id=disk0,if=none -device virtio-serial -chardev socket,id=charchannel0,path=/tmp/a,server,nowait -device virtserialport,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -device virtio-blk-pci,drive=disk1 -drive file=/srv/imgs/centos-7.2.qcow2,if=none,id=disk1
then the console showing:
><rescue> mount /dev/vdb1 /sysroot/
[   72.552185] SGI XFS with ACLs, security attributes, no debug enabled
[   72.568377] XFS (vdb1): Mounting V4 Filesystem
[   73.379679] XFS (vdb1): Starting recovery (logdev: internal)
[   73.406398] XFS (vdb1): Ending recovery (logdev: internal)
><rescue> statvfs
bash: statvfs: command not found
><rescue> stat -f /sysroot
  File: "/sysroot"
    ID: fd1100000000 Namelen: 255     Type: xfs
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 127147     Free: 93815      Available: 93815
Inodes: Total: 512000     Free: 511626

here the mount /dev/vdb1 device is the /boot partition from my guest, we can saw that
the free blocks are the same as python command, so I think the host kernel does not affect the result.
if I am wrong, pls correct me :)

Thanks,
Chen



>
>I wouldn't expect the numbers to be exactly the same, but libguestfs
>doesn't alter the numbers, it just passes them through.
>
>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>Fedora Windows cross-compiler. Compile Windows programs, test, and
>build Windows installers. Over 100 libraries supported.
>http://fedoraproject.org/wiki/MinGW