All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Priebe <s.priebe@profihost.ag>
To: Josef Bacik <jbacik@fusionio.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs deadlock in 3.5-rc3
Date: Mon, 25 Jun 2012 21:33:09 +0200	[thread overview]
Message-ID: <4FE8BCF5.4080605@profihost.ag> (raw)
In-Reply-To: <4FE8ADBA.20505@profihost.ag>

With v3.4 the same. Can't go back more as this really results in very 
fast corruption. Any ideas how to debug?

Stefan

Am 25.06.2012 20:28, schrieb Stefan Priebe:
> Am 25.06.2012 20:02, schrieb Josef Bacik:
>>>   >  Can you turn that off and see if you
>>>> can still reproduce the deadlock?  If so sysrq+w again, if not then
>>>> I know where
>>>> to look ;).  Thanks,
>>> without discard i can't reproduce but random write speed with ceph
>>> without discard is a LOT slower (around 8000 iops/s instead of
>>> 13000iops/s). So i don't know if it is discard or if i'm just not able
>>> to trigger it.
>>>
>>
>> Ouch, what kind of drive goes faster with discard _on_?  Anyway it
>> looks like
>> we're waiting for the discard to come back, so either its your drive
>> or theres a
>> bug in the block layer.  Maybe try an older kernel and see if it's
>> broken there,
>> and then bisect it down?  Thanks,
>
> Intel 520 series SSD. I can't try an older kernel version as ceph
> crashes with them pretty fast due to other bugs which where fixed with
> 3.5-rc1.
>
> Greets
> Stefan


  reply	other threads:[~2012-06-25 19:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-23  8:50 btrfs deadlock in 3.5-rc3 Stefan Priebe
2012-06-23 13:46 ` Michael
2012-06-23 14:55   ` Stefan Priebe
2012-06-25 13:08 ` Josef Bacik
2012-06-25 14:08   ` Stefan Priebe - Profihost AG
2012-06-25 14:20     ` Josef Bacik
2012-06-25 14:45       ` Stefan Priebe - Profihost AG
2012-06-25 14:48         ` Josef Bacik
2012-06-25 17:38           ` Stefan Priebe
2012-06-25 18:02             ` Josef Bacik
2012-06-25 18:28               ` Stefan Priebe
2012-06-25 19:33                 ` Stefan Priebe [this message]
2012-06-25 20:11                   ` Josef Bacik
2012-06-25 20:20                     ` Stefan Priebe
2012-06-25 20:23                       ` Josef Bacik
2012-06-25 20:33                         ` Stefan Priebe
2012-06-26 16:47                         ` Stefan Priebe
2012-06-26 20:14                           ` Josef Bacik
2012-06-26 20:19                             ` Stefan Priebe
2012-06-26 20:48                               ` Josef Bacik
2012-06-27  5:47                                 ` Stefan Priebe - Profihost AG
2012-06-27 13:30                                   ` Josef Bacik
2012-06-27 21:17                                   ` Josef Bacik

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=4FE8BCF5.4080605@profihost.ag \
    --to=s.priebe@profihost.ag \
    --cc=jbacik@fusionio.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.