From: Lennart Poettering <lennart@poettering.net>
To: Josef Bacik <jbacik@fb.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: price to pay for nocow file bit?
Date: Thu, 8 Jan 2015 14:30:36 +0100 [thread overview]
Message-ID: <20150108133036.GA23096@gardel-login> (raw)
In-Reply-To: <54AD929E.608@fb.com>
On Wed, 07.01.15 15:10, Josef Bacik (jbacik@fb.com) wrote:
> On 01/07/2015 12:43 PM, Lennart Poettering wrote:
> >Heya!
> >
> >Currently, systemd-journald's disk access patterns (appending to the
> >end of files, then updating a few pointers in the front) result in
> >awfully fragmented journal files on btrfs, which has a pretty
> >negative effect on performance when accessing them.
>
> I've been wondering if mount -o autodefrag would deal with this problem but
> I haven't had the chance to look into it.
Hmm, I am kinda interested in a solution that I can just implement in
systemd/journald now and that will then just make things work for
people suffering by the problem. I mean, I can hardly make systemd
patch the mount options of btrfs just because I place a journal file
on some fs...
Is "autodefrag" supposed to become a default one day?
Anyway, given the pros and cons I have now changed journald to set the
nocow bit on newly created journal files. When files are rotated (and
we hence know we will never ever write again to them) the bit is tried
to be unset again, and a defrag ioctl will be invoked right
after. btrfs currently silently ignores that we unset the bit, and
leaves it set, but I figure i should try to unset it anyway, in case
it learns that one day. After all, after rotating the files there's no
reason to treat the files special anymore...
I'll keep an eye on this, and see if I still get user complaints about
it. Should autodefrag become default eventually we can get rid of this
code in journald again.
One question regarding the btrfs defrag ioctl: playing around with it
it appears to be asynchronous, the defrag request is simply queued and
the ioctl returns immediately. Which is great for my usecase. However
I was wondering if it always was async like this? I googled a bit, and
found reports that defrag might take a while, but I am not sure if
those reports were about the ioctl taking so long, or the effect of
defrag actually hitting the disk...
Lennart
--
Lennart Poettering, Red Hat
next prev parent reply other threads:[~2015-01-08 13:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-07 17:43 price to pay for nocow file bit? Lennart Poettering
2015-01-07 20:10 ` Josef Bacik
2015-01-07 21:05 ` Goffredo Baroncelli
2015-01-07 22:06 ` Josef Bacik
2015-01-08 6:30 ` Duncan
2015-01-10 12:00 ` Martin Steigerwald
2015-01-10 12:23 ` Martin Steigerwald
2015-01-08 8:24 ` Chris Murphy
2015-01-08 8:35 ` Koen Kooi
2015-01-08 13:30 ` Lennart Poettering [this message]
2015-01-08 18:24 ` Konstantinos Skarlatos
2015-01-08 18:48 ` Goffredo Baroncelli
2015-01-09 15:52 ` David Sterba
2015-01-10 10:30 ` Martin Steigerwald
2015-01-11 20:39 ` Chris Murphy
2015-01-08 15:56 ` Zygo Blaxell
2015-01-08 16:53 ` Lennart Poettering
2015-01-08 18:36 ` Zygo Blaxell
2015-01-09 15:41 ` David Sterba
2015-01-09 16:14 ` Zygo Blaxell
2015-01-08 20:42 ` Roger Binns
2015-01-15 19:06 ` Chris Mason
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=20150108133036.GA23096@gardel-login \
--to=lennart@poettering.net \
--cc=jbacik@fb.com \
--cc=linux-btrfs@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 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).