From: Eric Sandeen <sandeen@redhat.com>
To: Wang Shilong <wangshilong1991@gmail.com>
Cc: linux-ext4@vger.kernel.org, adilger@dilger.ca,
Shuichi Ihara <sihara@ddn.com>
Subject: Re: [PATCH] ext4: add lazyinit stats support
Date: Mon, 16 May 2016 23:22:35 -0500 [thread overview]
Message-ID: <43a7d624-5fd1-a3a5-5f18-a84ebde86f1f@redhat.com> (raw)
In-Reply-To: <CAP9B-Q=7BUzkODy_PAsWi3YT3pYBcqMDWPR6kR6pCqFMDa_tzA@mail.gmail.com>
On 5/16/16 11:14 PM, Wang Shilong wrote:
> On Tue, May 17, 2016 at 11:59 AM, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 5/16/16 10:41 PM, Wang Shilong wrote:
>>> From: Wang Shilong <wshilong@ddn.com>
>>>
>>> Somtimes, we need figure out progress of Lazyinit
>>> in the background, this patch try to add stats support
>>> for it, output is something like:
>>>
>>> $ cat /sys/fs/ext4/vda/lazyinit_stats
>>> groups_finished: 80
>>> groups_total: 80
>>
>> A few thoughts:
>>
>> If this goes in, it should be documented in
>> Documentation/fs/ext4.txt, as well.
>>
>> I suppose it might be nice, but when do you think this
>> might be needed in real life?
>
> In our performances benchmarking, we want to wait
> Lazyinit finished before starting really benchmarking sometimes.
> (Since Lazyinit thread trigger some write background here)
>
> but there is no way to see what is progress of lazyinit.
> and we can only make sure there is no write from Device
> counter...
In that case you should just specify no lazyinit at mkfs time :)
>> Also: sysfs is technically supposed to be one value per
>> file, and (I think) just a number, no text. At least,
>> that's what every other ext4 device sysfs file has today,
>> so this should follow that precedent.
>>
>> And as far as I can tell, "groups total" is the total
>> uninit groups at mount time, not total in the filesystem,
>> so this would change on a remount? I think that's unexpected,
>> and not very useful.
>
> Yeah, From our usage, we need know progress of lazyiniting.
> So after remoutning, 'total' will be dynamically changed.
>
> We could store 'total' in superblock etc, but IMO it is
> a bit overhead here.
Agreed.
>>
>> Simply printing the remaining uninitialized block group
>> count might be enough, i.e.:
>>
>> $ cat /sys/fs/ext4/vda/lazyinit_remaining
>> 42
>
> Yup, this works fine for me.
>
> Thank you for your coments!
Sure thing; I'm still on the fence about usefulness, because if
anyone really cares to wait for it to hit zero, they probably
should have just changed their mkfs options to disable lazyinit.
But if you simply print remaining groups I think it is a very
simple and low-risk patch, so I wouldn't NAK it, either.
-Eric
>>
>> -Eric
next prev parent reply other threads:[~2016-05-17 4:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 3:41 [PATCH] ext4: add lazyinit stats support Wang Shilong
2016-05-17 3:59 ` Eric Sandeen
2016-05-17 4:14 ` Wang Shilong
2016-05-17 4:22 ` Eric Sandeen [this message]
2016-05-17 4:45 ` Theodore Ts'o
2016-05-17 5:36 ` Shuichi Ihara
2016-05-17 6:13 ` Theodore Ts'o
2016-05-17 4:05 ` Theodore Ts'o
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=43a7d624-5fd1-a3a5-5f18-a84ebde86f1f@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=sihara@ddn.com \
--cc=wangshilong1991@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).