Libguestfs - Jan 2018 - Re: virtdf outputs on host differs from df in guest

after install libguestfs_xfs,  all results are:



[using guestfish]
guestfish -N fs:xfs -m /dev/sda1 statvfs /
bsize: 4096
frsize: 4096
blocks: 24713
bfree: 23391
bavail: 23391
files: 51136
ffree: 51133
favail: 51133
fsid: 2049
flag: 4096
namemax: 255


[using virt-rescure]
virt-rescue -a test1.img
><rescue> mount /dev/sda1 /sysroot
><rescue> stat -f /sysroot
  File: "/sysroot" 
    ID: 80100000000 Namelen: 255     Type: xfs
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 24713      Free: 23391      Available: 23391
Inodes: Total: 51136      Free: 51133


the free numbers are the same. but the "virt-df" output is not
changed.


Thanks,
Chen






在 2018-01-07 20:22:28，"Richard W.M. Jones" <rjones@redhat.com>
写道：
>On Sun, Jan 07, 2018 at 08:11:58PM +0800, 陈帆 wrote:
>> Sorry for the late reply. when I used your method to execute command:
>>  $guestfish -N fs:xfs -m /dev/sda1 statvfs /
>> libguestfs: error: mkfs: xfs: /dev/sda1: mkfs.xfs: No such file or
directory
>> guestfish: error creating prepared disk image 'fs:xfs' on
'test1.img': failed to create filesystem (xfs): mkfs: xfs: /dev/sda1:
mkfs.xfs: No such file or directory
>
>You need to install ‘libguestfs-xfs’.
>
>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>virt-p2v converts physical machines to virtual machines.  Boot with a
>live CD or over the network (PXE) and turn machines into KVM guests.
>http://libguestfs.org/virt-v2v

There are some strange things going on with the kernel XFS driver.
Opening a filesystem for write or read-only makes a difference to the
stats returned.

With bit-for-bit identical filesystems:

  ><rescue> mount /dev/sda1 /sysroot
  ><rescue> stat -f /sysroot
    File: "/sysroot"
      ID: 80100000000 Namelen: 255     Type: xfs
  Block size: 4096       Fundamental block size: 4096
  Blocks: Total: 24713      Free: 23347      Available: 23347
  Inodes: Total: 51136      Free: 51133

vs:

  ><rescue> mount -o ro /dev/sda1 /sysroot
  ><rescue> stat -f /sysroot
    File: "/sysroot"
      ID: 80100000000 Namelen: 255     Type: xfs
  Block size: 4096       Fundamental block size: 4096
  Blocks: Total: 24713      Free: 24653      Available: 24653
  Inodes: Total: 51136      Free: 51133

virt-df always uses the ‘-o ro’ option.

Despite this virt-df itself is working fine:

  $ virt-df -a test1.img 
  Filesystem                     1K-blocks       Used  Available  Use%
  test1.img:/dev/sda1                98852        240      98612    1%

Using the calculations from here:

 
https://github.com/libguestfs/libguestfs/blob/ab0a3e0276656965021413194380ae602c05513d/df/output.c#L126-L136

                  blocks * bsize / 1024 = 24713 * 4096 / 1024 = 98852
(blocks - bfree) * bsize / 1024 = (24713-24653) * 4096 / 1024 = 240
                  bavail * bsize / 1024 = 24653 * 4096 / 1024 = 98612

So everything appears to be working fine, besides possibly odd stuff
going on in the kernel XFS driver.

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

The answer is attached.  In summary it's not a bug in virt-df,
nor df, nor the kernel.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

--qyHYMwAXsHLOQihY
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Return-Path: david@fromorbit.com
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	rhmail.home.annexia.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	UNPARSEABLE_RELAY autolearn=ham version=3.3.1
Received: from mail.corp.redhat.com [10.4.203.66]
	by rhmail.home.annexia.org with IMAP (fetchmail-6.3.17)
	for <rjones@localhost> (single-drop);
	Mon, 08 Jan 2018 11:43:47 +0000 (GMT)
Received: from zmta01.collab.prod.int.phx2.redhat.com (LHLO
	zmta01.collab.prod.int.phx2.redhat.com) (10.5.81.8) by
	zmail20.collab.prod.int.phx2.redhat.com with LMTP;
	Mon, 8 Jan 2018 06:43:14 -0500 (EST)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com
	[10.5.11.16])
	by zmta01.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id
	8C22E186679
	for <rjones@mail.corp.redhat.com>; Mon,  8 Jan 2018 06:43:14 -0500 (EST)
Received: by smtp.corp.redhat.com (Postfix)
	id 883B75C25E; Mon,  8 Jan 2018 11:43:14 +0000 (UTC)
Delivered-To: rjones@redhat.com
Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com
	[10.5.110.29])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 823DD5E1A0
	for <rjones@redhat.com>; Mon,  8 Jan 2018 11:43:14 +0000 (UTC)
Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net
	[150.101.137.141])
	by mx1.redhat.com (Postfix) with ESMTP id 27C7631A334
	for <rjones@redhat.com>; Mon,  8 Jan 2018 11:43:12 +0000 (UTC)
Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard)
	([59.167.129.252])
	by ipmail03.adl2.internode.on.net with ESMTP; 08 Jan 2018 22:13:09 +1030
Received: from dave by dastard with local (Exim 4.80)
	(envelope-from <david@fromorbit.com>)
	id 1eYVpZ-0006Nj-61; Mon, 08 Jan 2018 22:43:05 +1100
Date: Mon, 8 Jan 2018 22:43:05 +1100
From: Dave Chinner <david@fromorbit.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: statfs b_avail & b_free different if the filesystem is mounted
	readonly
Message-ID: <20180108114305.GA16421@dastard>
References: <20180108084450.GU2787@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180108084450.GU2787@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: Sender passed SPF test, Sender IP whitelisted by DNSRBL, ACL 207
	matched, not delayed by milter-greylist-4.5.16 (mx1.redhat.com
	[10.5.110.29]); Mon, 08 Jan 2018 11:43:12 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]);
	Mon, 08 Jan 2018 11:43:12 +0000 (UTC) for IP:'150.101.137.141'
	DOMAIN:'ipmail03.adl2.internode.on.net'
	HELO:'ipmail03.adl2.internode.on.net'
	FROM:'david@fromorbit.com' RCPT:''
X-RedHat-Spam-Score: -0.72  (RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL) 150.101.137.141
	ipmail03.adl2.internode.on.net 150.101.137.141
	ipmail03.adl2.internode.on.net <david@fromorbit.com>
X-Scanned-By: MIMEDefang 2.78 on 10.5.110.29
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16

On Mon, Jan 08, 2018 at 08:44:50AM +0000, Richard W.M. Jones
wrote:
> We had a question[1] posed by a libguestfs user who wondered why the
> output of virt-df and df differ for an XFS filesystem.  After
> looking into the details it turns out that the statfs(2) system call
> gives slightly different answers if the filesystem is mounted
> read-write vs read-only.
> 
>   ><rescue> mount /dev/sda1 /sysroot
>   ><rescue> stat -f /sysroot
>     File: "/sysroot"
>       ID: 80100000000 Namelen: 255     Type: xfs
>   Block size: 4096       Fundamental block size: 4096
>   Blocks: Total: 24713      Free: 23347      Available: 23347
>   Inodes: Total: 51136      Free: 51133
> 
> vs:
> 
>   ><rescue> mount -o ro /dev/sda1 /sysroot
>   ><rescue> stat -f /sysroot
>     File: "/sysroot"
>       ID: 80100000000 Namelen: 255     Type: xfs
>   Block size: 4096       Fundamental block size: 4096
>   Blocks: Total: 24713      Free: 24653      Available: 24653
>   Inodes: Total: 51136      Free: 51133
> 
> virt-df uses -o ro and in the df case the user had the
> filesystem mounted read-write, hence different results.
> 
> I looked into the kernel code and it's all pretty complicated.  I
> couldn't see exactly where this difference could come from.
Pretty simple when you know what to look for :P

This is off the top of my head, but the difference is mostly going
to be the ENOSPC reserve pool (xfs_reserve_blocks(), IIRC). it's
size is min(%5 total, 8192) blocks, and it's not reserved on a
read-only mount because it's only required for certain modifications
at ENOSPC that can't be reserved ahead of time (e.g. btree blocks
for an extent split during unwritten extent conversion at ENOSPC).

The numbers above will be slightly more than 5%, because total
blocks reported in fsstat doesn't include things like th space used
by the journal, whereas the reserve pool sizing just works from raw
sizes in the on-disk superblock.

So total fs size is at least 24713 blocks. 5% of that is 1235.6
blocks. The difference in free blocks is 24653 - 23347 = 1306
blocks. It's right in the ballpark I'd expect....
> My questions are: Is there a reason for this difference, and is one of
> the answers more correct than the other?
Yes, there's a reason. No, both are correct. :P

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--qyHYMwAXsHLOQihY--

thank you very much for your help :).

Thanks,

Chen


On 2018年01月08日 20:09, Richard W.M. Jones wrote:
> The answer is attached.  In summary it's not a bug in virt-df,
> nor df, nor the kernel.
>
> Rich.
>