Linux bcache driver list
 help / color / mirror / Atom feed
From: James Sefton <james-3k2nYdb70uTQXOPxS62xeg@public.gmane.org>
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Kernel Oops (bCache hangs on registering 3rd device)
Date: Sun, 4 Nov 2012 03:27:29 +0000 (UTC)	[thread overview]
Message-ID: <loom.20121104T035737-445@post.gmane.org> (raw)

Hi,

Seems I broke something.

I have run into this problem about 3 times now where bCache (or something!) 
seems to hang and I only just thought to check kern.log before trying to reboot 
so was previously assuming something else had just got stuck!

I only had 3 servers available to me and once this problem occurs, the servers 
seems to get stuck rebooting so I cannot do another test to confirm tonight.  (I 
have put a reboot request in for them to be force rebooted but that will not get 
actioned until tomorrow)

Here is what I know about the most recent time this happened:

I had already set-up and been using /dev/bcache0 and /dev/bcache1.  They are 
attached to the cache set and set to writeback.

The problem occurred when I ran "echo /dev/rbd2 >/sys/fs/bcache/register".   
This device had been newly formatted with "make-bcache -B /dev/rbd2"   (rbd2 is 
a SAN based block device)

If it makes any difference - these commands are in a script so the register 
command would have been run *immediately* after the make-bcache command 
returned.  (I am going to try sticking a sleep 3 or something in there tomorrow 
- just in case its related to trying to register the device so quickly after it 
was prepared)

At this point my console just stops.  I cannot CTRL+C to abort the echo command.
top shows increasing load average - presumably it thinks a process is stuck 
waiting for something.  Rebooting server kicks me out of console and then never 
comes back.

/dev/rbd0 and /dev/rbd1 are already registered at this point and were working 
fine.  If I open another console (did this before rebooting) and create 
/dev/rbd3, and then try and register it - the same happens again.

Here is what came up in kern.log:

http://pastebin.com/xNBuv3sj
(Using Gmane to post and it complained about long lines)

Any ideas?

Cheers,

James

             reply	other threads:[~2012-11-04  3:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-04  3:27 James Sefton [this message]
2012-11-05 13:01 ` Kernel Oops (bCache hangs on registering 3rd device) James Sefton
2012-11-05 13:15   ` James Sefton
     [not found]     ` <loom.20121105T140203-975-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-11-05 13:49       ` Joseph Glanville
2012-11-05 14:32         ` James Sefton
     [not found]           ` <loom.20121105T151725-920-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-11-05 15:37             ` Joseph Glanville
2012-11-05 16:02               ` James Sefton
     [not found]                 ` <loom.20121105T165829-696-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-11-05 16:20                   ` Joseph Glanville

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=loom.20121104T035737-445@post.gmane.org \
    --to=james-3k2nydb70utqxopxs62xeg@public.gmane.org \
    --cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.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