From: Chris Mason <clm@fb.com>
To: "hkbakke@gmail.com" <hkbakke@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Blocket for more than 120 seconds
Date: Mon, 16 Dec 2013 15:18:06 +0000 [thread overview]
Message-ID: <1387207097.18897.6.camel@ret.masoncoding.com> (raw)
In-Reply-To: <CAD_cGvF8-pxXXvwpB+yNYnKRW09S4c0VuKUGiWa7=8C2uFkvqA@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1137 bytes --]
On Sun, 2013-12-15 at 03:35 +0100, Hans-Kristian Bakke wrote:
> I have done some more testing. I turned off everything using the disk
> and only did defrag. I have created a script that gives me a list of
> the files with the most extents. I started from the top to improve the
> fragmentation of the worst files. The most fragmentet file was a file
> of about 32GB with over 250 000 extents!
> It seems that I can defrag a two to three largish (15-30GB) ~100 000
> extents files just fine, but after a while the system locks up (not a
> complete hard lock, but everythings hangs and a restart is necessary
> to get a fully working system again)
>
> It seems like defrag operations is triggering the issue. Probably in
> combination with the large and heavily fragmentet files.
>
I'm trying to understand how defrag factors into your backup workload?
Do you have autodefrag on, or are you running a defrag as part of the
backup when you see these stalls?
If not, we're seeing a different problem.
-chris
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±ý»k~ÏâØ^nr¡ö¦zË\x1aëh¨èÚ&£ûàz¿äz¹Þú+Ê+zf£¢·h§~Ûiÿÿïêÿêçz_è®\x0fæj:+v¨þ)ߣøm
next prev parent reply other threads:[~2013-12-16 15:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-14 20:30 Blocket for more than 120 seconds Hans-Kristian Bakke
2013-12-14 21:35 ` Chris Murphy
2013-12-14 23:19 ` Hans-Kristian Bakke
2013-12-14 23:50 ` Chris Murphy
2013-12-15 0:28 ` Hans-Kristian Bakke
2013-12-15 1:59 ` Chris Murphy
2013-12-15 2:35 ` Hans-Kristian Bakke
2013-12-15 13:24 ` Duncan
2013-12-15 14:51 ` Hans-Kristian Bakke
2013-12-15 23:08 ` Duncan
2013-12-16 0:06 ` Hans-Kristian Bakke
2013-12-16 10:19 ` Duncan
2013-12-16 10:55 ` Hans-Kristian Bakke
2013-12-16 15:00 ` Duncan
2013-12-16 15:18 ` Chris Mason [this message]
2013-12-16 16:32 ` Hans-Kristian Bakke
2013-12-16 18:16 ` Chris Mason
2013-12-16 18:22 ` Hans-Kristian Bakke
2013-12-16 18:33 ` Chris Mason
2013-12-16 18:41 ` Hans-Kristian Bakke
2013-12-15 3:47 ` George Mitchell
2013-12-15 23:39 ` Charles Cazabon
2013-12-16 0:16 ` Hans-Kristian Bakke
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=1387207097.18897.6.camel@ret.masoncoding.com \
--to=clm@fb.com \
--cc=hkbakke@gmail.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).