hi Jones, Thanks for your reply. 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/e6e23c4d77ee15779f833fd4fbe6c5...
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