From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: Autodefrag option with more delay?
Date: Sat, 10 Jan 2015 11:51:02 +0100 [thread overview]
Message-ID: <1939485.9eHmoT5uad@merkaba> (raw)
In-Reply-To: <24952376.hEFToVtt8e@merkaba>
Am Samstag, 10. Januar 2015, 11:41:57 schrieb Martin Steigerwald:
> Hi!
>
> On answering to the nocow file bit thread I wondered about the way
> autodefrag works. As I saw quite some time ago with a VM image on a 2,5
> inch external eSATA harddisk it kicks in quite quickly and seems to cause a
> *lot* of additional writes.
>
> I wonder about this case:
>
> merkaba:/home/martin/.local/share/akonadi/db_data/akonadi> filefrag
> parttable.ibd
> parttable.ibd: 8039 extents found
>
> Akonadi stores metadata about parts, like mails, contacts and so on in
> there. Now the most regular workload for this with a mail setup like here
> is:
>
> Add new data.
>
> It may not change much of the data after all the filtering of the mail to
> their mailfolders have done. Similarily with VM images after installation,
> much of the image may not be touched anymore then.
>
> I wonder how autodefrag would perform when it would take the *write hotness*
> of data into account. I.e. only kick in after data has cooled down a bit.
> That could help for any cases where applications only modify recently
> written data and leave older cold data alone. And I bet there may be quite
> some applications doing that. Including, but not limited to journald.
Okay, nope. Not journald, as, as far as I understand it it would never leave
the beginning of the file alone when it still writes to it. As MySQL would, I
think, just write into certain parts of the database file, i.e. there where it
would add the new records, as AFAIK MySQL stores the index seperate from the
tables if you use innodb_file_per_table.
I have seen fluentd tail plugin using a position file to track the position in
text based logfiles. It uses an external file as to not modify the logfile of the
application or syslog daemon. But actually writing the position pointers into
an external files IMHO makes a huge lot of sense for a copy on write filesystems
like BTRFS.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
prev parent reply other threads:[~2015-01-10 10:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-10 10:41 Autodefrag option with more delay? Martin Steigerwald
2015-01-10 10:51 ` Martin Steigerwald [this message]
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=1939485.9eHmoT5uad@merkaba \
--to=martin@lichtvoll.de \
--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).