> -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
> san
> -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 be
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, September 25, 2015 2:50 AM
> To: Marc Lehmann
> Cc: linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] sync/umount hang on 3.18.21, 1.4TB gone after crash
>
> On Wed, Sep 23, 201
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 at
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 abandon gcing the left segments
in current section, because anyway
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 a/fs/f2fs/recovery.c b/fs/f2fs/recovery.
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, 2015 6:54 AM
>>> To: Cha
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 number between 64 and 12
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
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: [f2fs-dev
On Fri, Sep 25, 2015 at 08:50:57AM +0200, Marc Lehmann wrote:
> 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 o
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
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% system time.
> >
> > Hmm
Previously, we skip dentry block writes when wbc is SYNC_NONE with no memory
pressure and the number of dirty pages is pretty small.
But, we didn't skip for normal data writes, which gives us not much big impact
on overall performance.
Moreover, by skipping some data writes, kworker falls into inf
On Fri, Sep 25, 2015 at 11:42:02AM -0700, Jaegeuk Kim
wrote:
> AFAIK, there-in *commit* means syncing metadata, not userdata. Doesn't it?
In general, no, they commit userdata, even if not necessarily at the same
time. ext* for example has three modes, and the default commits userdata
before the
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 make it short, the new m
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 keep it to address
> an
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, &count);
> After ioctl retruned succe
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
On Sat, Sep 26, 2015 at 07:25:51AM +0200, Marc Lehmann
wrote:
> Just for fun I'll start doing a -s64 run.
Same thing with -s64.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _
20 matches
Mail list logo
