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]
Message-ID: <bba7c78e-ead3-fb42-8d04-1e376a7809b0@linux.alibaba.com>
Date:   Wed, 1 Feb 2023 20:39:53 +0800
From:   Jingbo Xu <jefflexu@...ux.alibaba.com>
To:     Alexander Larsson <alexl@...hat.com>,
        Amir Goldstein <amir73il@...il.com>
Cc:     Gao Xiang <hsiangkao@...ux.alibaba.com>, gscrivan@...hat.com,
        brauner@...nel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, david@...morbit.com,
        viro@...iv.linux.org.uk, Vivek Goyal <vgoyal@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>
Subject: Re: [PATCH v3 0/6] Composefs: an opportunistically sharing verified
 image filesystem



On 2/1/23 5:52 PM, Alexander Larsson wrote:
> On Wed, 2023-02-01 at 16:59 +0800, Jingbo Xu wrote:
>>
>> I redid the test with suggestion from Amir, with all files inside the
>> erofs layer are redirected to the same lower block, e.g.
>> "/objects/00/014430a0b489d101c8a103ef829dd258448a13eb48b4d1e9ff0731d1
>> e82b92".
>>
>> The result is shown in the fourth line.
>>
>>                                   | uncached(ms)| cached(ms)
>> ----------------------------------|-------------|-----------
>> composefs (with digest)           | 326         | 135
>> erofs (w/o -T0)                   | 264         | 172
>> erofs (w/o -T0) + overlayfs       | 651         | 238
>> erofs (hacked and redirect to one |             |
>> lower block) + overlayfs          | 400         | 230
>>
>> It seems that the "lazy lookup" in overlayfs indeed optimizes in this
>> situation.
>>
>>
>> The performance gap in cached situation (especially comparing
>> composefs
>> and standalone erofs) is still under investigation and I will see if
>> there's any hint by perf diff.
> 
> The fact that plain erofs is faster than composefs uncached, but slower
> cached is very strange. Also, see my other mail where erofs+ovl cached
> is slower than squashfs+ovl cached for me. Something seems to be off
> with the cached erofs case...
> 


I tested erofs with ACL disabled (see fourth line).

				  | uncached(ms)| cached(ms)
----------------------------------|-------------|-----------
composefs (with digest)		  | 326		| 135
squashfs (uncompressed)		  | 406		| 172
erofs (w/o -T0)			  | 264		| 172
erofs (w/o -T0, mount with noacl) | 225		| 141


The remained perf difference in cached situation might be noisy and may
be due to the difference of test environment.


-- 
Thanks,
Jingbo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ