From: Roger Binns <rogerb@rogerbinns.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs-transaction blocked for more than 120 seconds
Date: Sat, 04 Jan 2014 12:48:44 -0800 [thread overview]
Message-ID: <la9s31$v5b$1@ger.gmane.org> (raw)
In-Reply-To: <20140103172506.GA10021@merlins.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/01/14 09:25, Marc MERLIN wrote:
> Is there even a reason for this not to become a default mount option
> in newer kernels?
autodefrag can go insane because it is unbounded. For example I have a
4GB RAM system (3.12, no gui) that kept hanging. I eventually managed to
work out the cause being a MySQL database (about 750MB of data only being
used by tt-rss refreshing RSS feeds every 4 hours).
autodefrag would eventually consume all the RAM and 20GB of swap kicking
off the OOM killer and with so little RAM left for anything else that the
only recourse was sysrq keys.
What I'd love to see is some sort of background worker that does sensible
things. For example it could defragment files, but pick the ones that
need it the most, and I'd love to see extra copies of (meta)data in
currently unused space that is freed as needed. deduping is another
worthwhile option. So is recompressing data that hasn't changed recently
but using larger block sizes to get more effective ratios. Some of these
happen at the moment but they are independent and you have to be aware of
the caveats.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEARECAAYFAlLIc6wACgkQmOOfHg372QQgjgCeJp1sZQ0+Y7WRGE+U+IFljiDY
MgQAnjEBspyJZvTC2caEn1Qkn942vPQ2
=rhNY
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-01-04 20:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-31 11:46 btrfs-transaction blocked for more than 120 seconds Sulla
2014-01-01 12:37 ` Duncan
2014-01-01 20:08 ` Sulla
2014-01-02 8:38 ` Duncan
2014-01-03 1:24 ` Kai Krakow
2014-01-03 9:18 ` Duncan
2014-01-05 0:12 ` Sulla
2014-01-03 17:25 ` Marc MERLIN
2014-01-03 21:34 ` Duncan
2014-01-05 6:39 ` Marc MERLIN
2014-01-05 17:09 ` Chris Murphy
2014-01-05 17:54 ` Jim Salter
2014-01-05 19:57 ` Duncan
2014-01-05 20:44 ` Chris Murphy
2014-01-08 3:22 ` Marc MERLIN
2014-01-08 9:45 ` Duncan
2014-01-04 20:48 ` Roger Binns [this message]
2014-01-02 8:49 ` Jojo
2014-01-05 20:32 ` Chris Murphy
2014-01-05 21:17 ` Sulla
2014-01-05 22:36 ` Brendan Hide
2014-01-05 22:57 ` Roman Mamedov
2014-01-07 10:22 ` Brendan Hide
2014-01-06 0:15 ` Chris Murphy
2014-01-06 0:19 ` Chris Murphy
2014-01-05 23:48 ` Chris Murphy
2014-01-05 23:57 ` Chris Murphy
2014-01-06 0:25 ` Sulla
2014-01-06 0:49 ` Chris Murphy
[not found] ` <52CA06FE.2030802@gmx.at>
2014-01-06 1:55 ` Chris Murphy
[not found] <ADin1n00P0VAdqd01DioM9>
2014-01-05 20:44 ` Duncan
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='la9s31$v5b$1@ger.gmane.org' \
--to=rogerb@rogerbinns.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).