From: George Mitchell <george@chinilu.com>
To: "Szőts Ákos" <szotsaki@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: systemd "journalctl" is 1.89sec on ext4, 1.49 min on btrfs
Date: Mon, 27 May 2013 09:42:13 -0700 [thread overview]
Message-ID: <51A38CE5.1010003@chinilu.com> (raw)
In-Reply-To: <16735484.PAleCPYpY8@noname>
I have gotten what appear to be large increases in speed out of btrfs by
defragmentation of meta data. The manual defragmentation process takes
forever as you have to defragment incrementally directory by directory.
I was at the point where KDE startup times were getting abysmal (along
with journalctl, etc) and the multiple drives would churn incessantly on
startup. In the case of KDE, I found almost magical improvement with
one operation: `btrfs filesystem defrag /usr/share`. I am currently
going through the whole system deframenting directory by directory. Its
amazing, it proceeds quite quickly and then hits a directory at random
where it sits and plods away seemingly forever before moving on. I am
convinced that there is something going on here with meta data
fragmentation that, at times, is seriously affecting performance. I
*think* that autodefrag, once its out the door will hopefully solve
this, in the mean time I am trying to come up with some sort of way to
schedule an anacron job to deal with this issue. But my suggestion
would be that you try defragging your /var filesystem as thoroughly as
possible on the meta data side.
On 05/27/2013 09:21 AM, Szőts Ákos wrote:
> Dear list,
>
> I have two openSUSE 12.3 systems with kernel 3.9. On one of them there's an
> ext4 partition, while on the other there's a btrfs.
>
> I issued a "time journalctl -b --no-pager" command on both systems. This shows
> the logs from the current boot without passing them to "less".
>
> On ext4 (3.9.3):
> real 0m1.898s
> user 0m0.291s
> sys 0m0.105s
>
> On btrfs (3.9.2):
> real 1m49.698s
> user 0m0.102s
> sys 0m0.470s
>
> Journalctl on btrfs was always this slow, some btrfsck were made on the file
> system too, but I don't think it was corrupted. On just the first run it's
> sluggish, after it's fast as the ext4 one.
>
> Is it a known issue or can I help somehow debugging this further?
>
> Best regards,
>
> Ákos Szőts
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2013-05-27 16:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-27 16:21 systemd "journalctl" is 1.89sec on ext4, 1.49 min on btrfs Szőts Ákos
[not found] ` <CAFvQSYTtuH99nqMb6589xJgwsrSG6fD02XzU3ji=dSmJokMxTw@mail.gmail.com>
2013-05-27 16:36 ` Clemens Eisserer
2013-05-27 16:42 ` George Mitchell [this message]
2013-05-27 17:47 ` Sergei Trofimovich
2013-05-27 22:00 ` Szőts Ákos
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=51A38CE5.1010003@chinilu.com \
--to=george@chinilu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=szotsaki@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).