On Thu, Oct 01, 2015 at 08:51:24PM +0200, Marc Lehmann wrote:
> On Thu, Oct 01, 2015 at 02:11:20PM +0200, Marc Lehmann
> wrote:
> > WOW, THAT HELPED A LOT. While the peak throughput seems quite a bit lower
>
> Ok, for completeness, here is the full log and a description of what was
> going on.
>
On Thu, Oct 01, 2015 at 02:11:20PM +0200, Marc Lehmann
wrote:
> WOW, THAT HELPED A LOT. While the peak throughput seems quite a bit lower
Ok, for completeness, here is the full log and a description of what was
going on.
http://data.plan9.de/f2fs.s64.noinline.full.trace.xz
status at the end +
On Tue, Sep 29, 2015 at 04:13:10PM -0700, Jaegeuk Kim
wrote:
> > First thing, the allocation-failure-on-mount is still in the backported 3.18
> > f2fs module. If it's supposed to be gone in that version, it's not working:
> >
> > http://ue.tst.eu/a1bc4796012bd7191ab2ada566d4cd22.txt
>
> Oops, i
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, September 30, 2015 7:13 AM
> To: Marc Lehmann
> Cc: linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] write performance difference 3.18.21/git f2fs
>
> On Tue, Se
On Tue, Sep 29, 2015 at 01:02:04PM +0200, Marc Lehmann wrote:
> On Mon, Sep 28, 2015 at 10:59:44AM -0700, Jaegeuk Kim
> wrote:
> > In order to verify this also, could you retrieve the following logs?
>
> First thing, the allocation-failure-on-mount is still in the backported 3.18
> f2fs module.
On Mon, Sep 28, 2015 at 10:59:44AM -0700, Jaegeuk Kim
wrote:
> In order to verify this also, could you retrieve the following logs?
First thing, the allocation-failure-on-mount is still in the backported 3.18
f2fs module. If it's supposed to be gone in that version, it's not working:
http://ue.
On Sat, Sep 26, 2015 at 03:59:57PM +0200, Marc Lehmann wrote:
> On Sat, Sep 26, 2015 at 12:52:53AM -0700, Jaegeuk Kim
> wrote:
> > > Just for fun I'll start doing a -s64 run.
>
> (which had the same result).
>
> > Okay, so before finding bad commits, if possible, can you get block traces?
>
>
On Sat, Sep 26, 2015 at 12:52:53AM -0700, Jaegeuk Kim
wrote:
> > Just for fun I'll start doing a -s64 run.
(which had the same result).
> Okay, so before finding bad commits, if possible, can you get block traces?
If you can teach me how to, sure!
In the meantime, maybe what happened is that
On Sat, Sep 26, 2015 at 07:25:51AM +0200, Marc Lehmann wrote:
> 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 f
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
==-- _
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
11 matches
Mail list logo
