All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: <akpm@linux-foundation.org>, <songmuchun@bytedance.com>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] hugetlbfs: fix confusing hugetlbfs stat
Date: Fri, 22 Jul 2022 14:38:10 +0800	[thread overview]
Message-ID: <f277d8ac-8091-78b4-e168-5dfd87314889@huawei.com> (raw)
In-Reply-To: <YtnvFBn8tSm7y/mV@monkey>

On 2022/7/22 8:28, Mike Kravetz wrote:
> On 07/21/22 21:16, Miaohe Lin wrote:
>> When size option is not specified, f_blocks, f_bavail and f_bfree will be
>> set to -1 instead of 0. Likewise, when nr_inodes is not specified, f_files
>> and f_ffree will be set to -1 too. Check max_hpages and max_inodes against
>> -1 first to make sure 0 is reported for max/free/used when no limit is set
>> as the comment states.
> 
> Just curious, where are you seeing values reported as -1?  The check

From the standard statvfs() function.

> for sbinfo->spool was supposed to handle these cases.  Seems like it

sbinfo->spool could be created when ctx->max_hpages == -1 while
ctx->min_hpages != -1 in hugetlbfs_fill_super.

> should handle the max_hpages == -1 case.  But, it doesn't look like it
> considers the max_inodes == -1 case.
> 
> If I create/mount a hugetlb filesystem without specifying size or nr_inodes,
> df seems to report zero instead of -1.
> 
> Just want to understand the reasoning behind the change.

I wrote a test program:

#include <sys/statvfs.h>
#include <stdio.h>

int main(void)
{
	struct statvfs buf;

	if (statvfs("/root/huge/", &buf) == -1) {
 		printf("statvfs() error\n");
		return -1;
	}
	printf("f_blocks %lld, f_bavail %lld, f_bfree %lld, f_files %lld, f_ffree %lld\n",
		buf.f_blocks, buf.f_bavail, buf.f_bfree, buf.f_files, buf.f_ffree);
	return 0;
}

And test it in my env:
[root@localhost ~]# mount -t hugetlbfs none /root/huge/
[root@localhost ~]# ./stat
f_blocks 0, f_bavail 0, f_bfree 0, f_files 0, f_ffree 0
[root@localhost ~]# umount /root/huge/
[root@localhost ~]# mount -t hugetlbfs -o min_size=32M none /root/huge/
[root@localhost ~]# ./stat
f_blocks -1, f_bavail -1, f_bfree -1, f_files -1, f_ffree -1
[root@localhost ~]# umount /root/huge/
[root@localhost ~]# mount -t hugetlbfs -o min_size=32M,size=64M none /root/huge/
[root@localhost ~]# ./stat
f_blocks 32, f_bavail 32, f_bfree 32, f_files -1, f_ffree -1
[root@localhost ~]# umount /root/huge/
[root@localhost ~]# mount -t hugetlbfs -o min_size=32M,size=64M,nr_inodes=1024 none /root/huge/
[root@localhost ~]# ./stat
f_blocks 32, f_bavail 32, f_bfree 32, f_files 1024, f_ffree 1023
[root@localhost ~]# umount /root/huge/

Or am I miss something?

> 

Thanks.

  reply	other threads:[~2022-07-22  6:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 13:16 [PATCH 0/5] A few cleanup and fixup patches for hugetlbfs Miaohe Lin
2022-07-21 13:16 ` [PATCH 1/5] hugetlbfs: use helper macro SZ_1{K,M} Miaohe Lin
2022-07-21 23:13   ` Mike Kravetz
2022-07-21 13:16 ` [PATCH 2/5] hugetlbfs: remove unneeded hugetlbfs_ops forward declaration Miaohe Lin
2022-07-21 23:14   ` Mike Kravetz
2022-07-21 13:16 ` [PATCH 3/5] hugetlbfs: remove unneeded header file Miaohe Lin
2022-07-21 23:18   ` Mike Kravetz
2022-07-22  6:12     ` Miaohe Lin
2022-07-21 13:16 ` [PATCH 4/5] hugetlbfs: cleanup some comments in inode.c Miaohe Lin
2022-07-21 23:23   ` Mike Kravetz
2022-07-22  6:19     ` Miaohe Lin
2022-07-22 21:38       ` Mike Kravetz
2022-07-21 13:16 ` [PATCH 5/5] hugetlbfs: fix confusing hugetlbfs stat Miaohe Lin
2022-07-22  0:28   ` Mike Kravetz
2022-07-22  6:38     ` Miaohe Lin [this message]
2022-07-22 22:55       ` Mike Kravetz
2022-07-23  2:56         ` Miaohe Lin
2022-07-25 23:40           ` Mike Kravetz
2022-07-26  2:01             ` Miaohe Lin

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=f277d8ac-8091-78b4-e168-5dfd87314889@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=songmuchun@bytedance.com \
    /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.