[f2fs-dev] write performance difference 3.18.21/git f2fs

Ok, before I tried the f2fs git I made another short test with the original 3.18.21 f2fs, and it was as fast as before. Then I used the faulty f2fs module,. which forced a reboot. Now I started to redo the 3.18.21 test + git f2fs, with the same parameters (specifically, -s90), and while it didn't

Re: [f2fs-dev] write performance difference 3.18.21/4.2.1

On Fri, Sep 25, 2015 at 05:47:12PM +0800, Chao Yu wrote: > Hi Marc Jaegeuk, > > > -Original Message- > > From: Marc Lehmann [mailto:schm...@schmorp.de] > > Sent: Friday, September 25, 2015 2:51 PM > > To: Jaegeuk Kim > > Cc: linux-f2fs-devel@lists.sourceforge.net > > Subject: Re:

Re: [f2fs-dev] sync/umount hang on 3.18.21, 1.4TB gone after crash

Hi Chao, [snip] > > It seems there was no fsync after sync at all. That's why f2fs recovered > > back to > > the latest checkpoint. Anyway, I'm thinking that it's worth to add a kind of > > periodic checkpoints. > > Agree, I have that in my mind for long time, since Yunlei said that they > may

Re: [f2fs-dev] sync/umount hang on 3.18.21, 1.4TB gone after crash

On Fri, Sep 25, 2015 at 08:00:19AM +0200, Marc Lehmann wrote: > On Thu, Sep 24, 2015 at 11:50:23AM -0700, Jaegeuk Kim > wrote: > > > When I came back after ~10 hours, I found a number of hung task messages > > > in syslog, and when I entered sync, sync was consuming 100%

Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning

On Fri, Sep 25, 2015 at 07:42:25AM +0200, Marc Lehmann wrote: > On Thu, Sep 24, 2015 at 10:27:49AM -0700, Jaegeuk Kim > wrote: > > > In the end, I might settle with -s64, and currently do tests with -s90. > > > > Got it. But why -s90? :) > > He :) It's a nothing-special

Re: [f2fs-dev] [PATCH v2] f2fs: fix to correct freed section number during gc

On Fri, Sep 25, 2015 at 05:50:55PM +0800, Chao Yu wrote: > This patch fixes to maintain the right section count freed in garbage > collecting when triggering a foreground gc. > > Besides, when a foreground gc is running on current selected section, once > we fail to gc one segment, it's better to

Re: [f2fs-dev] write performance difference 3.18.21/4.2.1

On Fri, Sep 25, 2015 at 05:47:12PM +0800, Chao Yu wrote: > Please revert the commit 7c5e466755ff ("f2fs: readahead cp payload > pages when mount") since in this commit we try to access invalid > SIT_I(sbi)->sit_base_addr which should be inited later. Wow, you are fast. To

Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning

On Fri, Sep 25, 2015 at 10:45:46AM -0700, Jaegeuk Kim wrote: > > He :) It's a nothing-special number between 64 and 128, that's all. > > Oh, then, I don't think that is a good magic number. Care to share why? :) > It seems that you decided to use -s64, so it'd better to

Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning

On Fri, Sep 25, 2015 at 04:05:48PM +0800, Chao Yu wrote: > Actually, we should set the value of 'count' parameter to indicate how many > times we want to do gc in one batch, at most 16 times in a loop for each > ioctl invoking: > ioctl(fd, F2FS_IOC_GC, ); > After

Re: [f2fs-dev] sync/umount hang on 3.18.21, 1.4TB gone after crash

On Thu, Sep 24, 2015 at 11:50:23AM -0700, Jaegeuk Kim wrote: > > When I came back after ~10 hours, I found a number of hung task messages > > in syslog, and when I entered sync, sync was consuming 100% system time. > > Hmm, at this time, it would be good to check what

Re: [f2fs-dev] sync/umount hang on 3.18.21, 1.4TB gone after crash

On Fri, Sep 25, 2015 at 08:00:19AM +0200, Marc Lehmann wrote: > On Thu, Sep 24, 2015 at 11:50:23AM -0700, Jaegeuk Kim > wrote: > > > When I came back after ~10 hours, I found a number of hung task messages > > > in syslog, and when I entered sync, sync

Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning

> -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Friday, September 25, 2015 1:21 AM > To: Marc Lehmann > Cc: Chao Yu; linux-f2fs-devel@lists.sourceforge.net > Subject: Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious > corruption, much more > sane

Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning

> -Original Message- > From: Marc Lehmann [mailto:schm...@schmorp.de] > Sent: Thursday, September 24, 2015 7:30 AM > To: Chao Yu > Cc: 'Jaegeuk Kim'; linux-f2fs-devel@lists.sourceforge.net > Subject: Re: [f2fs-dev] SMR drive test 2; 128GB partition; no obvious > corruption, much more >

Re: [f2fs-dev] [PATCH] f2fs: fix to correct freed section number during gc

Hi Jaegeuk, > On Sep 24, 2015, at 5:08 AM, Jaegeuk Kim wrote: > > Hi Chao, > > On Wed, Sep 23, 2015 at 06:11:36PM +0800, Chao Yu wrote: >> Hi Jaegeuk, >> >>> -Original Message- >>> From: Jaegeuk Kim [mailto:jaeg...@kernel.org] >>> Sent: Wednesday, September 23,

Re: [f2fs-dev] write performance difference 3.18.21/4.2.1

On Thu, Sep 24, 2015 at 11:28:36AM -0700, Jaegeuk Kim wrote: > One thing that we can try is to run the latest f2fs source in v3.18. > This branch supports f2fs for v3.18. Ok, please bear with me, the last time I built my own kernel was during the 2.4 timeframe, and this is a

Re: [f2fs-dev] write performance difference 3.18.21/4.2.1

Hi Marc Jaegeuk, > -Original Message- > From: Marc Lehmann [mailto:schm...@schmorp.de] > Sent: Friday, September 25, 2015 2:51 PM > To: Jaegeuk Kim > Cc: linux-f2fs-devel@lists.sourceforge.net > Subject: Re: [f2fs-dev] write performance difference 3.18.21/4.2.1 > > On Thu, Sep 24, 2015

[f2fs-dev] [PATCH] f2fs: remove unneeded f2fs_{, un}lock_op in do_recover_data()

Protecting recovery flow by using cp_rwsem is not needed, since we have prevent triggering any checkpoint by locking cp_mutex previously. Signed-off-by: Chao Yu --- fs/f2fs/recovery.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git