hi Jones, Thanks for your reply.
At 2018-01-04 19:41:27, "Richard W.M. Jones" <rjones(a)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/e6e23c4d77ee15779f833fd4fbe...
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