Hi Chao,
On Fri, May 08, 2020 at 05:47:09PM +0800, Chao Yu wrote:
> For lz4 worst compress case, caller should allocate buffer with size
> of LZ4_compressBound(inputsize) for target compressed data storing.
>
> However lz4 supports partial data compression, so we can get rid of
> output buffer
Is this v2?
On 05/08, Daeho Jeong wrote:
> From: Daeho Jeong
>
> Now, if writing pages and releasing compress blocks occur
> simultaneously, and releasing cblocks is executed more than one time
> to a file, then total block count of filesystem and block count of the
> file could be incorrect
On 05/08, Jaegeuk Kim wrote:
> Is this v2?
nvm. it seems the same version.
>
> On 05/08, Daeho Jeong wrote:
> > From: Daeho Jeong
> >
> > Now, if writing pages and releasing compress blocks occur
> > simultaneously, and releasing cblocks is executed more than one time
> > to a file, then
Hi Daeho,
Please let me integrate this patch into the original patch since it is still in
the dev branch.
Thanks,
On 05/08, Daeho Jeong wrote:
> From: Daeho Jeong
>
> Now, if writing pages and releasing compress blocks occur
> simultaneously, and releasing cblocks is executed more than one
On 2020/5/8 12:25, Daeho Jeong wrote:
> From: Daeho Jeong
>
> Now, if writing pages and releasing compress blocks occur
> simultaneously, and releasing cblocks is executed more than one time
> to a file, then total block count of filesystem and block count of the
> file could be incorrect and
I moved checking i_compr_blocks phrase after calling inode_lock()
already, because we should check this after writing pages.
So, if it fails to check i_compr_blocks, we need to call inode_unlock().
Am I missing something?
2020년 5월 8일 (금) 오후 3:50, Chao Yu 님이 작성:
>
> On 2020/5/8 12:25, Daeho
On 2020/5/8 17:29, Daeho Jeong wrote:
> From: Daeho Jeong
>
> Now, if writing pages and releasing compress blocks occur
> simultaneously, and releasing cblocks is executed more than one time
> to a file, then total block count of filesystem and block count of the
> file could be incorrect and
From: Daeho Jeong
Now, if writing pages and releasing compress blocks occur
simultaneously, and releasing cblocks is executed more than one time
to a file, then total block count of filesystem and block count of the
file could be incorrect and damaged.
We have to execute releasing compress
Hi Sayali,
In order to address the perf regression, how about this?
>From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Fri, 8 May 2020 09:08:37 -0700
Subject: [PATCH] f2fs: avoid double lock for cp_rwsem during checkpoint
There could be a scenario
blk_plugging doesn't seem to give any benefit.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 97b6378554b40..cc9dd3bbf2188 100644
--- a/fs/f2fs/checkpoint.c
+++
On 2020/5/9 0:10, Jaegeuk Kim wrote:
> Hi Sayali,
>
> In order to address the perf regression, how about this?
>
>>From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim
> Date: Fri, 8 May 2020 09:08:37 -0700
> Subject: [PATCH] f2fs: avoid double lock for
Hi Xiang,
On 2020/5/8 18:23, Gao Xiang wrote:
> Hi Chao,
>
> On Fri, May 08, 2020 at 05:47:09PM +0800, Chao Yu wrote:
>> For lz4 worst compress case, caller should allocate buffer with size
>> of LZ4_compressBound(inputsize) for target compressed data storing.
>>
>> However lz4 supports partial
Great, thanks for checking~! :)
2020년 5월 8일 (금) 오후 3:42, Chao Yu 님이 작성:
>
> On 2020/5/8 11:30, Daeho Jeong wrote:
> > I am a little bit confused.
> >
> > In compress_log=2 (4 pages),
> >
> > Every compression algorithm will set the cc->nr_cpages to 5 pages like
> > below.
> >
> >
On 2020/5/8 11:30, Daeho Jeong wrote:
> I am a little bit confused.
>
> In compress_log=2 (4 pages),
>
> Every compression algorithm will set the cc->nr_cpages to 5 pages like below.
>
> max_len = COMPRESS_HEADER_SIZE + cc->clen;
> cc->nr_cpages = DIV_ROUND_UP(max_len,
On 2020/5/8 14:58, Daeho Jeong wrote:
> I moved checking i_compr_blocks phrase after calling inode_lock()
> already, because we should check this after writing pages.
>
> So, if it fails to check i_compr_blocks, we need to call inode_unlock().
>
> Am I missing something?
After applying this
On 2020/5/7 15:59, Eric Biggers wrote:
> From: Eric Biggers
>
> We need to call fscrypt_free_filename() to free the memory allocated by
> fscrypt_setup_filename().
>
> Fixes: b06af2aff28b ("f2fs: convert inline_dir early before starting rename")
Thanks for fixing this.
> Cc: # v5.6+
>
From: Daeho Jeong
Now, if writing pages and releasing compress blocks occur
simultaneously, and releasing cblocks is executed more than one time
to a file, then total block count of filesystem and block count of the
file could be incorrect and damaged.
We have to execute releasing compress
For lz4 worst compress case, caller should allocate buffer with size
of LZ4_compressBound(inputsize) for target compressed data storing.
However lz4 supports partial data compression, so we can get rid of
output buffer size limitation now, then we can avoid 2 * 4KB size
intermediate buffer
In f2fs_try_to_free_nids(), .nid_list_lock spinlock critical region will
increase as expected shrink number increase, to avoid spining other CPUs
for long time, we change to release nid caches with small batch each time
under .nid_list_lock coverage.
Signed-off-by: Chao Yu
---
v2:
- shrink free
Oops,
I will re-check it.
Thanks,
2020년 5월 8일 (금) 오후 4:09, Chao Yu 님이 작성:
>
> On 2020/5/8 14:58, Daeho Jeong wrote:
> > I moved checking i_compr_blocks phrase after calling inode_lock()
> > already, because we should check this after writing pages.
> >
> > So, if it fails to check
20 matches
Mail list logo
