From: Kai Krakow <hurikhan77+btrfs@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: hard freezes with 3.9.0 during io-intensive loads
Date: Thu, 16 May 2013 09:19:38 +0200 [thread overview]
Message-ID: <btde6a-5an.ln1@hurikhan.ath.cx> (raw)
In-Reply-To: 518C9B55.3050008@jan-o-sch.net
Jan Schmidt <list.btrfs@jan-o-sch.net> schrieb:
>>>> Apparently, it's not fixed. The system does not freeze now but it threw
>>>> multiple backtraces right in front of my Xorg session. The backtraces
>>>> look a little bit different now. Here's what I got:
>>>>
>>>> https://gist.github.com/kakra/8a340f006d01e146865d
>>>>
>>>> Occurence while running "bedup dedup --defrag --size-cutoff
>>>> $((1024*1024))" which was currently dedup'ing my backup volume with
>>>> daily snapshots filled by "rsync --inplace" - so I suppose some file
>>>> contents are pretty scattered.
>>>
>>> At least that looks different for now. I'm not certain about all the
>>> fixes in btrfs-next. Can you give it a try and bisect if btrfs-next is
>>> good? That would be really helpful.
>>
>> I'd prefer to not bisect my production system kernel... That will
>> probably take ages as running the "reproducable test" takes about 30-60
>> minutes before the problem hits my system. At least unless you had a
>> suggestion how to speed up the process... ;-)
>
> I see, hoped it would be something quicker.
>
>> I saw the pull request with those fixes, so I supsect it didn't go into
>> 3.9.1 but rather will go into 3.9.2?
>
> Probably. However, those patches obviously weren't enough to solve your
> problem. We don't submit a lot of things to stable, so they are likely to
> remain the only btrfs related changes in there, which would mean it is
> unlikely to help with your problem.
I turned off autodefrag which fixes these problems. So without bisect I can
at least say the problem is probably somewhere in the new snapshot-aware
defragmentation code which came with 3.9.0 or related to the introduction of
the same.
3.9.2 still does not fix anything. I'll go with autodefrag=off for the
moment until I hear some news in that regard. With this new information, is
it still helpful to get a metadata image from me? It should be reproducable
if you enable autodefrag or defragment cow'ed files.
Regards,
Kai
next prev parent reply other threads:[~2013-05-16 7:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-05 10:25 hard freezes with 3.9.0 during io-intensive loads Kai Krakow
2013-05-05 16:10 ` Kai Krakow
2013-05-05 18:33 ` cwillu
2013-05-06 8:55 ` Jan Schmidt
2013-05-06 9:12 ` Harald Glatt
2013-05-06 20:29 ` Kai Krakow
2013-05-07 6:08 ` Jan Schmidt
2013-05-07 21:16 ` Kai Krakow
2013-05-08 0:24 ` Kai Krakow
2013-05-08 11:05 ` Jan Schmidt
2013-05-09 23:30 ` Kai Krakow
2013-05-10 7:01 ` Jan Schmidt
2013-05-11 10:01 ` Kai Krakow
2013-05-16 7:19 ` Kai Krakow [this message]
2013-05-17 15:43 ` Jan Schmidt
2013-05-06 0:39 ` Josef Bacik
2013-05-06 7:47 ` Kai Krakow
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=btde6a-5an.ln1@hurikhan.ath.cx \
--to=hurikhan77+btrfs@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).