From: "Richard W.M. Jones" <rjones@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: statfs b_avail & b_free different if the filesystem is mounted readonly
Date: Mon, 8 Jan 2018 08:44:50 +0000 [thread overview]
Message-ID: <20180108084450.GU2787@redhat.com> (raw)
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.
My questions are: Is there a reason for this difference, and is one of
the answers more correct than the other?
Rich.
[1] https://www.redhat.com/archives/libguestfs/2018-January/msg00002.html
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
next reply other threads:[~2018-01-08 8:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 8:44 Richard W.M. Jones [this message]
2018-01-08 11:43 ` statfs b_avail & b_free different if the filesystem is mounted readonly Dave Chinner
2018-01-08 12:06 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180108084450.GU2787@redhat.com \
--to=rjones@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.