From: Marc Lehmann <schmorp@schmorp.de>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: write performance difference 3.18.21/git f2fs
Date: Sat, 26 Sep 2015 15:59:57 +0200 [thread overview]
Message-ID: <20150926135957.GB9860@schmorp.de> (raw)
In-Reply-To: <20150926075253.GD13619@jaegeuk-mac02.hsd1.ca.comcast.net>
On Sat, Sep 26, 2015 at 12:52:53AM -0700, Jaegeuk Kim <jaegeuk@kernel.org> 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 f2fs leaves some gaps (e.g.
for alignment) when writing now, and didn't in 3.18? That would somehow
explain what I see.
Except that with the 3.18 code, there is virtually no read access while
writing to the disk for hours. With f2fs git, there is a small 16kb read
every half a minute or so, and after a while, a lot of "reading a few
mb/s, while writing a few mb/s".
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
------------------------------------------------------------------------------
next prev parent reply other threads:[~2015-09-26 14:00 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-23 21:58 sync/umount hang on 3.18.21, 1.4TB gone after crash Marc Lehmann
2015-09-23 23:11 ` write performance difference 3.18.21/4.2.1 Marc Lehmann
2015-09-24 18:28 ` Jaegeuk Kim
2015-09-24 23:20 ` Marc Lehmann
2015-09-24 23:27 ` Marc Lehmann
2015-09-25 6:50 ` Marc Lehmann
2015-09-25 9:47 ` Chao Yu
2015-09-25 18:20 ` Jaegeuk Kim
2015-09-26 3:22 ` Marc Lehmann
2015-09-26 5:25 ` write performance difference 3.18.21/git f2fs Marc Lehmann
2015-09-26 5:57 ` Marc Lehmann
2015-09-26 7:52 ` Jaegeuk Kim
2015-09-26 13:59 ` Marc Lehmann [this message]
2015-09-28 17:59 ` Jaegeuk Kim
2015-09-29 11:02 ` Marc Lehmann
2015-09-29 23:13 ` Jaegeuk Kim
2015-09-30 9:02 ` Chao Yu
2015-10-01 12:11 ` Marc Lehmann
2015-10-01 18:51 ` Marc Lehmann
2015-10-02 8:53 ` 100% system time hang with git f2fs Marc Lehmann
2015-10-02 16:51 ` Jaegeuk Kim
2015-10-03 6:29 ` Marc Lehmann
2015-10-02 16:46 ` write performance difference 3.18.21/git f2fs Jaegeuk Kim
2015-10-04 9:40 ` near disk full performance (full 8TB) Marc Lehmann
2015-09-26 7:48 ` write performance difference 3.18.21/4.2.1 Jaegeuk Kim
2015-09-25 18:26 ` Jaegeuk Kim
2015-09-24 18:50 ` sync/umount hang on 3.18.21, 1.4TB gone after crash Jaegeuk Kim
2015-09-25 6:00 ` Marc Lehmann
2015-09-25 6:01 ` Marc Lehmann
2015-09-25 18:42 ` Jaegeuk Kim
2015-09-26 3:08 ` Marc Lehmann
2015-09-26 7:27 ` Jaegeuk Kim
2015-09-25 9:13 ` Chao Yu
2015-09-25 18:30 ` Jaegeuk Kim
-- strict thread matches above, loose matches on Subject: below --
2015-08-08 20:50 general stability of f2fs? Marc Lehmann
2015-08-10 20:31 ` Jaegeuk Kim
2015-08-10 20:53 ` Marc Lehmann
2015-08-10 21:58 ` Jaegeuk Kim
2015-08-13 0:26 ` Marc Lehmann
2015-08-14 23:07 ` Jaegeuk Kim
2015-09-20 23:59 ` finally testing with SMR drives Marc Lehmann
2015-09-21 8:17 ` SMR drive test 1; 512GB partition; very slow + unfixable corruption Marc Lehmann
2015-09-21 8:19 ` Marc Lehmann
2015-09-21 9:58 ` SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning Marc Lehmann
2015-09-22 20:22 ` SMR drive test 3: full 8TB partition, mount problems, fsck error after delete Marc Lehmann
2015-09-22 23:08 ` Jaegeuk Kim
2015-09-23 3:50 ` Marc Lehmann
2015-09-23 1:12 ` SMR drive test 2; 128GB partition; no obvious corruption, much more sane behaviour, weird overprovisioning Jaegeuk Kim
2015-09-23 4:15 ` Marc Lehmann
2015-09-23 6:00 ` Marc Lehmann
2015-09-23 8:55 ` Chao Yu
2015-09-23 23:30 ` Marc Lehmann
2015-09-23 23:43 ` Marc Lehmann
2015-09-24 17:21 ` Jaegeuk Kim
2015-09-25 8:28 ` Chao Yu
2015-09-25 8:05 ` Chao Yu
2015-09-26 3:42 ` Marc Lehmann
2015-09-23 22:08 ` Jaegeuk Kim
2015-09-23 23:39 ` Marc Lehmann
2015-09-24 17:27 ` Jaegeuk Kim
2015-09-25 5:42 ` Marc Lehmann
2015-09-25 17:45 ` Jaegeuk Kim
2015-09-26 3:32 ` Marc Lehmann
2015-09-26 7:36 ` Jaegeuk Kim
2015-09-26 13:53 ` Marc Lehmann
2015-09-28 18:33 ` Jaegeuk Kim
2015-09-29 7:36 ` Marc Lehmann
2015-09-23 6:06 ` Marc Lehmann
2015-09-23 9:10 ` Chao Yu
2015-09-23 21:30 ` Jaegeuk Kim
2015-09-23 23:11 ` Marc Lehmann
2015-09-23 21:29 ` Jaegeuk Kim
2015-09-23 23:24 ` Marc Lehmann
2015-09-24 17:51 ` 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=20150926135957.GB9860@schmorp.de \
--to=schmorp@schmorp.de \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/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.