lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 16 May 2016 23:22:35 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Wang Shilong <wangshilong1991@...il.com>
Cc:	linux-ext4@...r.kernel.org, adilger@...ger.ca,
	Shuichi Ihara <sihara@....com>
Subject: Re: [PATCH] ext4: add lazyinit stats support

On 5/16/16 11:14 PM, Wang Shilong wrote:
> On Tue, May 17, 2016 at 11:59 AM, Eric Sandeen <sandeen@...hat.com> wrote:
>> On 5/16/16 10:41 PM, Wang Shilong wrote:
>>> From: Wang Shilong <wshilong@....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

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ