All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [RFC PATCH v5] f2fs: support data compression
Date: Tue, 14 Jan 2020 14:48:37 -0800	[thread overview]
Message-ID: <20200114224837.GB19274@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <326f0049-936c-7dc4-52c3-aa64e13b2cc6@huawei.com>

On 01/14, Chao Yu wrote:
> On 2020/1/14 0:11, Jaegeuk Kim wrote:
> > On 01/13, Chao Yu wrote:
> >> On 2020/1/12 2:02, Jaegeuk Kim wrote:
> >>> On 01/11, Chao Yu wrote:
> >>>> On 2020/1/11 7:52, Jaegeuk Kim wrote:
> >>>>> On 01/06, Jaegeuk Kim wrote:
> >>>>>> On 01/06, Chao Yu wrote:
> >>>>>>> On 2020/1/3 14:50, Chao Yu wrote:
> >>>>>>>> This works to me. Could you run fsstress tests on compressed root directory?
> >>>>>>>> It seems still there are some bugs.
> >>>>>>>
> >>>>>>> Jaegeuk,
> >>>>>>>
> >>>>>>> Did you mean running por_fsstress testcase?
> >>>>>>>
> >>>>>>> Now, at least I didn't hit any problem for normal fsstress case.
> >>>>>>
> >>>>>> Yup. por_fsstress
> >>>>>
> >>>>> Please check https://github.com/jaegeuk/f2fs/commits/g-dev-test.
> >>>>> I've fixed
> >>>>> - truncation offset
> >>>>> - i_compressed_blocks and its lock coverage
> >>>>> - error handling
> >>>>> - etc
> >>>>
> >>>> I changed as below, and por_fsstress stops panic the system.
> >>>>
> >>>> Could you merge all these fixes into original patch?
> >>>
> >>> Yup, let m roll up some early patches first once test results become good.
> >>
> >> I didn't encounter issue any more, how about por_fsstress test result in your
> >> enviornment? If there is, please share the call stack with me.
> > 
> > Sure, will do, once I hit an issue. BTW, I'm hitting another unreacheable nat
> > entry issue during por_stress without compression. :(
> 
> Did you enable any features during por_fsstress test?
> 
> I only hit below warning during por_fsstress test on image w/o compression.
> 
> ------------[ cut here ]------------
> WARNING: CPU: 10 PID: 33483 at fs/fs-writeback.c:1448 __writeback_single_inode+0x28c/0x340
> Call Trace:
>  writeback_single_inode+0xad/0x120
>  sync_inode_metadata+0x3d/0x60
>  f2fs_sync_inode_meta+0x90/0xe0 [f2fs]
>  block_operations+0x17c/0x360 [f2fs]
>  f2fs_write_checkpoint+0x101/0xff0 [f2fs]
>  f2fs_sync_fs+0xa8/0x130 [f2fs]
>  f2fs_do_sync_file+0x19c/0x880 [f2fs]
>  do_fsync+0x38/0x60
>  __x64_sys_fsync+0x10/0x20
>  do_syscall_64+0x5f/0x220
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Does gc_mutex patch fix this?

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >> Thanks,
> >>
> >>>
> >>>>
> >>>> >From bb17d7d77fe0b8a3e3632a7026550800ab9609e9 Mon Sep 17 00:00:00 2001
> >>>> From: Chao Yu <yuchao0@huawei.com>
> >>>> Date: Sat, 11 Jan 2020 16:58:20 +0800
> >>>> Subject: [PATCH] f2fs: compress: fix f2fs_put_rpages_mapping()
> >>>>
> >>>> Signed-off-by: Chao Yu <yuchao0@huawei.com>
> >>>> ---
> >>>>  fs/f2fs/compress.c | 30 +++++++++++++++---------------
> >>>>  1 file changed, 15 insertions(+), 15 deletions(-)
> >>>>
> >>>> diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
> >>>> index 502cd0ddc2a7..5c6a31d84ce4 100644
> >>>> --- a/fs/f2fs/compress.c
> >>>> +++ b/fs/f2fs/compress.c
> >>>> @@ -74,18 +74,10 @@ static void f2fs_put_compressed_page(struct page *page)
> >>>>  }
> >>>>
> >>>>  static void f2fs_drop_rpages(struct compress_ctx *cc,
> >>>> -		struct address_space *mapping, int len, bool unlock)
> >>>> +					int len, bool unlock)
> >>>>  {
> >>>>  	unsigned int i;
> >>>>  	for (i = 0; i < len; i++) {
> >>>> -		if (mapping) {
> >>>> -			pgoff_t start = start_idx_of_cluster(cc);
> >>>> -			struct page *page = find_get_page(mapping, start + i);
> >>>> -
> >>>> -			put_page(page);
> >>>> -			put_page(page);
> >>>> -			cc->rpages[i] = NULL;
> >>>> -		}
> >>>>  		if (!cc->rpages[i])
> >>>>  			continue;
> >>>>  		if (unlock)
> >>>> @@ -97,18 +89,25 @@ static void f2fs_drop_rpages(struct compress_ctx *cc,
> >>>>
> >>>>  static void f2fs_put_rpages(struct compress_ctx *cc)
> >>>>  {
> >>>> -	f2fs_drop_rpages(cc, NULL, cc->cluster_size, false);
> >>>> +	f2fs_drop_rpages(cc, cc->cluster_size, false);
> >>>>  }
> >>>>
> >>>>  static void f2fs_unlock_rpages(struct compress_ctx *cc, int len)
> >>>>  {
> >>>> -	f2fs_drop_rpages(cc, NULL, len, true);
> >>>> +	f2fs_drop_rpages(cc, len, true);
> >>>>  }
> >>>>
> >>>>  static void f2fs_put_rpages_mapping(struct compress_ctx *cc,
> >>>> -				struct address_space *mapping, int len)
> >>>> +				struct address_space *mapping,
> >>>> +				pgoff_t start, int len)
> >>>>  {
> >>>> -	f2fs_drop_rpages(cc, mapping, len, false);
> >>>> +	int i;
> >>>> +	for (i = 0; i < len; i++) {
> >>>> +		struct page *page = find_get_page(mapping, start + i);
> >>>> +
> >>>> +		put_page(page);
> >>>> +		put_page(page);
> >>>> +	}
> >>>>  }
> >>>>
> >>>>  static void f2fs_put_rpages_wbc(struct compress_ctx *cc,
> >>>> @@ -680,7 +679,8 @@ static int prepare_compress_overwrite(struct compress_ctx *cc,
> >>>>
> >>>>  		if (!PageUptodate(page)) {
> >>>>  			f2fs_unlock_rpages(cc, i + 1);
> >>>> -			f2fs_put_rpages_mapping(cc, mapping, cc->cluster_size);
> >>>> +			f2fs_put_rpages_mapping(cc, mapping, start_idx,
> >>>> +					cc->cluster_size);
> >>>>  			f2fs_destroy_compress_ctx(cc);
> >>>>  			goto retry;
> >>>>  		}
> >>>> @@ -714,7 +714,7 @@ static int prepare_compress_overwrite(struct compress_ctx *cc,
> >>>>  unlock_pages:
> >>>>  	f2fs_unlock_rpages(cc, i);
> >>>>  release_pages:
> >>>> -	f2fs_put_rpages_mapping(cc, mapping, i);
> >>>> +	f2fs_put_rpages_mapping(cc, mapping, start_idx, i);
> >>>>  	f2fs_destroy_compress_ctx(cc);
> >>>>  	return ret;
> >>>>  }
> >>>> -- 
> >>>> 2.18.0.rc1
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> One another fix in f2fs-tools as well.
> >>>>> https://github.com/jaegeuk/f2fs-tools
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>> .
> >>>>>
> >>> .
> >>>
> > .
> > 

WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [RFC PATCH v5] f2fs: support data compression
Date: Tue, 14 Jan 2020 14:48:37 -0800	[thread overview]
Message-ID: <20200114224837.GB19274@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <326f0049-936c-7dc4-52c3-aa64e13b2cc6@huawei.com>

On 01/14, Chao Yu wrote:
> On 2020/1/14 0:11, Jaegeuk Kim wrote:
> > On 01/13, Chao Yu wrote:
> >> On 2020/1/12 2:02, Jaegeuk Kim wrote:
> >>> On 01/11, Chao Yu wrote:
> >>>> On 2020/1/11 7:52, Jaegeuk Kim wrote:
> >>>>> On 01/06, Jaegeuk Kim wrote:
> >>>>>> On 01/06, Chao Yu wrote:
> >>>>>>> On 2020/1/3 14:50, Chao Yu wrote:
> >>>>>>>> This works to me. Could you run fsstress tests on compressed root directory?
> >>>>>>>> It seems still there are some bugs.
> >>>>>>>
> >>>>>>> Jaegeuk,
> >>>>>>>
> >>>>>>> Did you mean running por_fsstress testcase?
> >>>>>>>
> >>>>>>> Now, at least I didn't hit any problem for normal fsstress case.
> >>>>>>
> >>>>>> Yup. por_fsstress
> >>>>>
> >>>>> Please check https://github.com/jaegeuk/f2fs/commits/g-dev-test.
> >>>>> I've fixed
> >>>>> - truncation offset
> >>>>> - i_compressed_blocks and its lock coverage
> >>>>> - error handling
> >>>>> - etc
> >>>>
> >>>> I changed as below, and por_fsstress stops panic the system.
> >>>>
> >>>> Could you merge all these fixes into original patch?
> >>>
> >>> Yup, let m roll up some early patches first once test results become good.
> >>
> >> I didn't encounter issue any more, how about por_fsstress test result in your
> >> enviornment? If there is, please share the call stack with me.
> > 
> > Sure, will do, once I hit an issue. BTW, I'm hitting another unreacheable nat
> > entry issue during por_stress without compression. :(
> 
> Did you enable any features during por_fsstress test?
> 
> I only hit below warning during por_fsstress test on image w/o compression.
> 
> ------------[ cut here ]------------
> WARNING: CPU: 10 PID: 33483 at fs/fs-writeback.c:1448 __writeback_single_inode+0x28c/0x340
> Call Trace:
>  writeback_single_inode+0xad/0x120
>  sync_inode_metadata+0x3d/0x60
>  f2fs_sync_inode_meta+0x90/0xe0 [f2fs]
>  block_operations+0x17c/0x360 [f2fs]
>  f2fs_write_checkpoint+0x101/0xff0 [f2fs]
>  f2fs_sync_fs+0xa8/0x130 [f2fs]
>  f2fs_do_sync_file+0x19c/0x880 [f2fs]
>  do_fsync+0x38/0x60
>  __x64_sys_fsync+0x10/0x20
>  do_syscall_64+0x5f/0x220
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Does gc_mutex patch fix this?

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >> Thanks,
> >>
> >>>
> >>>>
> >>>> >From bb17d7d77fe0b8a3e3632a7026550800ab9609e9 Mon Sep 17 00:00:00 2001
> >>>> From: Chao Yu <yuchao0@huawei.com>
> >>>> Date: Sat, 11 Jan 2020 16:58:20 +0800
> >>>> Subject: [PATCH] f2fs: compress: fix f2fs_put_rpages_mapping()
> >>>>
> >>>> Signed-off-by: Chao Yu <yuchao0@huawei.com>
> >>>> ---
> >>>>  fs/f2fs/compress.c | 30 +++++++++++++++---------------
> >>>>  1 file changed, 15 insertions(+), 15 deletions(-)
> >>>>
> >>>> diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
> >>>> index 502cd0ddc2a7..5c6a31d84ce4 100644
> >>>> --- a/fs/f2fs/compress.c
> >>>> +++ b/fs/f2fs/compress.c
> >>>> @@ -74,18 +74,10 @@ static void f2fs_put_compressed_page(struct page *page)
> >>>>  }
> >>>>
> >>>>  static void f2fs_drop_rpages(struct compress_ctx *cc,
> >>>> -		struct address_space *mapping, int len, bool unlock)
> >>>> +					int len, bool unlock)
> >>>>  {
> >>>>  	unsigned int i;
> >>>>  	for (i = 0; i < len; i++) {
> >>>> -		if (mapping) {
> >>>> -			pgoff_t start = start_idx_of_cluster(cc);
> >>>> -			struct page *page = find_get_page(mapping, start + i);
> >>>> -
> >>>> -			put_page(page);
> >>>> -			put_page(page);
> >>>> -			cc->rpages[i] = NULL;
> >>>> -		}
> >>>>  		if (!cc->rpages[i])
> >>>>  			continue;
> >>>>  		if (unlock)
> >>>> @@ -97,18 +89,25 @@ static void f2fs_drop_rpages(struct compress_ctx *cc,
> >>>>
> >>>>  static void f2fs_put_rpages(struct compress_ctx *cc)
> >>>>  {
> >>>> -	f2fs_drop_rpages(cc, NULL, cc->cluster_size, false);
> >>>> +	f2fs_drop_rpages(cc, cc->cluster_size, false);
> >>>>  }
> >>>>
> >>>>  static void f2fs_unlock_rpages(struct compress_ctx *cc, int len)
> >>>>  {
> >>>> -	f2fs_drop_rpages(cc, NULL, len, true);
> >>>> +	f2fs_drop_rpages(cc, len, true);
> >>>>  }
> >>>>
> >>>>  static void f2fs_put_rpages_mapping(struct compress_ctx *cc,
> >>>> -				struct address_space *mapping, int len)
> >>>> +				struct address_space *mapping,
> >>>> +				pgoff_t start, int len)
> >>>>  {
> >>>> -	f2fs_drop_rpages(cc, mapping, len, false);
> >>>> +	int i;
> >>>> +	for (i = 0; i < len; i++) {
> >>>> +		struct page *page = find_get_page(mapping, start + i);
> >>>> +
> >>>> +		put_page(page);
> >>>> +		put_page(page);
> >>>> +	}
> >>>>  }
> >>>>
> >>>>  static void f2fs_put_rpages_wbc(struct compress_ctx *cc,
> >>>> @@ -680,7 +679,8 @@ static int prepare_compress_overwrite(struct compress_ctx *cc,
> >>>>
> >>>>  		if (!PageUptodate(page)) {
> >>>>  			f2fs_unlock_rpages(cc, i + 1);
> >>>> -			f2fs_put_rpages_mapping(cc, mapping, cc->cluster_size);
> >>>> +			f2fs_put_rpages_mapping(cc, mapping, start_idx,
> >>>> +					cc->cluster_size);
> >>>>  			f2fs_destroy_compress_ctx(cc);
> >>>>  			goto retry;
> >>>>  		}
> >>>> @@ -714,7 +714,7 @@ static int prepare_compress_overwrite(struct compress_ctx *cc,
> >>>>  unlock_pages:
> >>>>  	f2fs_unlock_rpages(cc, i);
> >>>>  release_pages:
> >>>> -	f2fs_put_rpages_mapping(cc, mapping, i);
> >>>> +	f2fs_put_rpages_mapping(cc, mapping, start_idx, i);
> >>>>  	f2fs_destroy_compress_ctx(cc);
> >>>>  	return ret;
> >>>>  }
> >>>> -- 
> >>>> 2.18.0.rc1
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> One another fix in f2fs-tools as well.
> >>>>> https://github.com/jaegeuk/f2fs-tools
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>> .
> >>>>>
> >>> .
> >>>
> > .
> > 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-01-14 22:48 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16  6:28 [RFC PATCH v5] f2fs: support data compression Chao Yu
2019-12-16  6:28 ` [f2fs-dev] " Chao Yu
2019-12-16 11:08 ` Markus Elfring
2019-12-16 11:08   ` [f2fs-dev] " Markus Elfring
2019-12-16 13:12   ` Chao Yu
2019-12-16 13:12     ` [f2fs-dev] " Chao Yu
2019-12-16 11:32 ` Markus Elfring
2019-12-16 11:32   ` [f2fs-dev] " Markus Elfring
2019-12-16 13:24   ` Chao Yu
2019-12-16 13:24     ` Chao Yu
2019-12-16 11:51 ` Markus Elfring
2019-12-16 11:51   ` [f2fs-dev] " Markus Elfring
2019-12-16 11:51   ` Markus Elfring
2019-12-16 13:28   ` Chao Yu
2019-12-16 13:28     ` [f2fs-dev] " Chao Yu
2019-12-16 13:28     ` Chao Yu
2019-12-16 13:38     ` [v5] " Markus Elfring
2019-12-16 13:38       ` [f2fs-dev] " Markus Elfring
2019-12-16 13:38       ` Markus Elfring
2019-12-18 21:46 ` [RFC PATCH v5] " Jaegeuk Kim
2019-12-18 21:46   ` [f2fs-dev] " Jaegeuk Kim
2019-12-23  3:32   ` Chao Yu
2019-12-23  3:32     ` [f2fs-dev] " Chao Yu
2019-12-23  3:58     ` Chao Yu
2019-12-23  3:58       ` Chao Yu
2019-12-23 19:29     ` Jaegeuk Kim
2019-12-23 19:29       ` [f2fs-dev] " Jaegeuk Kim
2019-12-31  0:46     ` Jaegeuk Kim
2019-12-31  0:46       ` [f2fs-dev] " Jaegeuk Kim
2019-12-31  1:45       ` Chao Yu
2019-12-31  1:45         ` [f2fs-dev] " Chao Yu
2020-01-02 18:18         ` Jaegeuk Kim
2020-01-02 18:18           ` [f2fs-dev] " Jaegeuk Kim
2020-01-02 19:00           ` Jaegeuk Kim
2020-01-02 19:00             ` [f2fs-dev] " Jaegeuk Kim
2020-01-03  6:50             ` Chao Yu
2020-01-03  6:50               ` [f2fs-dev] " Chao Yu
2020-01-06  9:01               ` Chao Yu
2020-01-06  9:01                 ` Chao Yu
2020-01-06 18:16                 ` Jaegeuk Kim
2020-01-06 18:16                   ` Jaegeuk Kim
2020-01-10 23:52                   ` Jaegeuk Kim
2020-01-10 23:52                     ` Jaegeuk Kim
2020-01-11  9:08                     ` Chao Yu
2020-01-11  9:08                       ` Chao Yu
2020-01-11 18:02                       ` Jaegeuk Kim
2020-01-11 18:02                         ` Jaegeuk Kim
2020-01-13  8:56                         ` Chao Yu
2020-01-13  8:56                           ` Chao Yu
2020-01-13 16:11                           ` Jaegeuk Kim
2020-01-13 16:11                             ` Jaegeuk Kim
2020-01-14  1:52                             ` Chao Yu
2020-01-14  1:52                               ` Chao Yu
2020-01-14 22:48                               ` Jaegeuk Kim [this message]
2020-01-14 22:48                                 ` Jaegeuk Kim
2020-01-15 10:12                                 ` Chao Yu
2020-01-15 10:12                                   ` Chao Yu
2020-01-15 21:38                                   ` Jaegeuk Kim
2020-01-15 21:38                                     ` Jaegeuk Kim
2020-01-03  1:19           ` Chao Yu
2020-01-03  1:19             ` [f2fs-dev] " Chao Yu
2019-12-19  9:53 ` Geert Uytterhoeven
2019-12-19  9:53   ` [f2fs-dev] " Geert Uytterhoeven
2019-12-23  3:36   ` Chao Yu
2019-12-23  3:36     ` [f2fs-dev] " Chao Yu
2019-12-19 10:18 ` Geert Uytterhoeven
2019-12-19 10:18   ` [f2fs-dev] " Geert Uytterhoeven
2019-12-19 10:25 ` Geert Uytterhoeven
2019-12-19 10:25   ` [f2fs-dev] " Geert Uytterhoeven
2019-12-20 21:26   ` Jaegeuk Kim
2019-12-20 21:26     ` [f2fs-dev] " Jaegeuk Kim

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=20200114224837.GB19274@jaegeuk-macbookpro.roam.corp.google.com \
    --to=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuchao0@huawei.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.