All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Bashkirtsev <vladimir@bashkirtsev.com>
To: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Crash of almost full ceph
Date: Sat, 04 Aug 2012 20:07:48 +0930	[thread overview]
Message-ID: <501CFB7C.1040601@bashkirtsev.com> (raw)

Hello,

Yesterday finally I have managed to screw up my installation of ceph! :)

My ceph was at 80% capacity. I have rebooted one of OSDs remotely and 
managed to screw up with fstab. Host failed to come up and while I was 
driving from home to my office ceph took recovery action. But it meant 
that it has filled up another OSDs completely and it has failed. Ceph 
continued to recover and killed other OSDs in the same fashion. Not 
quite good. Attempt to restart OSDs was in vain: they were unable to 
test for xattrs because file system was full and only growing file 
system allowed them to restart.

Now this leads me to a question/proposal: is there a feature which 
allows ceph to halt recovery process if any of live OSDs exceeding say 
95% percent capacity? It is quite distinct from what is considered full 
or near full OSD as any writes when OSD is near full or full coming from 
clients and inability to write leads to client lock up. But halting 
recovery should allow clients to continue even so ceph is in degraded 
state. It does not make sense to me to allow ceph go from degraded state 
to crashed state when no client needs it.

Regards,
Vladimir

             reply	other threads:[~2012-08-04 10:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-04 10:37 Vladimir Bashkirtsev [this message]
2012-08-06 16:25 ` Crash of almost full ceph Gregory Farnum
2012-08-06 16:39   ` Vladimir Bashkirtsev
2012-08-06 16:53     ` Gregory Farnum
     [not found]       ` <5020B458.40106@bashkirtsev.com>
2012-08-07 19:35         ` Gregory Farnum

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=501CFB7C.1040601@bashkirtsev.com \
    --to=vladimir@bashkirtsev.com \
    --cc=ceph-devel@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.