From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 71641] Unreasonable performance degradation in ext4 with full data journaling
Date: Fri, 07 Mar 2014 17:57:32 +0000 [thread overview]
Message-ID: <bug-71641-13602-wlWuvG8NpE@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-71641-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=71641
--- Comment #2 from Chia-Hung Chang <fredchang.tc@gmail.com> ---
>
> How big was the ramdisk? Since all of the blocks are going through
> the journal, even if it is on the journal, it requires more commits
> and thus more checkpoint operations, which means more updates to the
> disk. A bigger journal will help minimize this issue.
>
> Would you be willing to grab block traces for both the disk and the
> external journal device?
>
> I will add that the workload of "dd if=/dev/zero of=file" is probably
> the worst case for data=journal, and if that's really what you are
> doing, it's a case of "doctor, doctor, it hurts when I do that". All
> file systems modes will have strengths and weaknesses, and your use
> case one where I would simply tell people, "don't use that mode".
>
> If you want to work on improving it, that's great. Gather data, and
> if we can figure out an easy way to improve things, great. But I'll
> warn you ahead of time this is not necessarily something I view as
> "unreasonable", nor is it something that I would consider a high
> priority thing to fix.
>
- Ted
I use two sizes of ramdisk, 128MB and 1024MB. With 1024MB journal area, the
performance is slight improved. But performance degradation is still
significant.
I am willing to grab block traces. Please tell me how to get the traces you
want.
As you can see that the performance degradation of applying data=journal in
raid5 is 80%, which makes it hard to use. If I know where the problem is, I
will try to improve it.
Thanks for your help.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2014-03-07 17:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 11:39 [Bug 71641] New: Unreasonable performance degradation in ext4 with full data journaling bugzilla-daemon
2014-03-07 16:20 ` Theodore Ts'o
2014-03-07 16:20 ` [Bug 71641] " bugzilla-daemon
2014-03-07 17:57 ` bugzilla-daemon [this message]
2014-03-19 9:35 ` bugzilla-daemon
2014-03-20 4:09 ` bugzilla-daemon
2014-03-20 12:47 ` bugzilla-daemon
2014-03-21 8:16 ` bugzilla-daemon
2014-03-21 8:17 ` bugzilla-daemon
2014-03-21 8:44 ` bugzilla-daemon
2014-03-21 8:48 ` bugzilla-daemon
2014-03-21 16:04 ` bugzilla-daemon
2014-03-26 10:30 ` bugzilla-daemon
2014-03-26 13:40 ` bugzilla-daemon
2014-03-28 10:23 ` bugzilla-daemon
2014-03-28 10:55 ` bugzilla-daemon
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=bug-71641-13602-wlWuvG8NpE@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@vger.kernel.org \
/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.