linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

  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).