All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.