On Tue, Sep 29, 2015 at 04:13:10PM -0700, Jaegeuk Kim <jaeg...@kernel.org> 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, it seems I missed some other allocations too. > Could you pull the v3.18 again? I changed the patch.
Hmm, I don't see any relevant change in the log, but I will use the newest version. > > (event tracing is cool btw., thanks for showing me :) > > Thank you for the below traces. > I have two suspicious things from the traces where: > > 1. several inline_data conversion of existing files > Could you test -o noinline_data and share its trace too? WOW, THAT HELPED A LOT. While the peak throughput seems quite a bit lower than 3.18 stock (seems, because this might be caused by less peaky, more smooth, writes - I am only looking at it with my eyes), it could keep up with the reading side easily, and performance didn't degrade so far. The test continues, but here is the trace for the first 368GB: http://data.plan9.de/f2fs.s64.noinline.trace.xz I had a cursory look at the previous traces, and didn't see any obvious problem (if anything, git f2fs seems to leave fewer gaps). However, both versions do leave quite a few gaps. I wanted to look at reordering, which might be a problem, too, but didn't get to that. Obviously, inline_data was the culprit for the especially bad performance. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ ------------------------------------------------------------------------------ _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
