_pool has become full, and ceph has
marked it down.
>From that point, it is not possible to resume the benchmark,
and we are not able to get the cluster healthy (HEALTH_OK) back again.
Any ideas will be very much appreciated.
Thank you very much for your time and your help.
Best regards
tom that indicates that something is wrong?
(for example, a disk is about to fail)
(3) How can we fix the "slow requests"?
(4) What's the meaning of "blocked ops", and how can they be
blocked so long? (67000 seconds is more than 18 hours!)
(5) How can we fix the "bl
Ubuntu 14.04 LTS 64-bits, kernel 3.16
- 5 monitors, 128GB RAM each
- 6 osd hosts, 32GB RAM each, 20 osds per host, 1 HDD WD Green 2TB per osd
- (and 6 more osds host to arrive soon)
- 10 GbE interconnection
Thank you very much indeed.
Best regards,
- Xavier Serrano
- LCAC, Laborator
l in normal cluster operation (when propagating the replicas,
for instance). And slow/blocked requests/ops do not occur (or at
least, occur less frequently).
Does this make sense to you? Any other thoughts?
Thank you very much again for your time.
- Xavier Serrano
- LCAC, Laboratori de Càlcul
- Depart
Hello,
On Wed May 27 21:20:49 2015, Christian Balzer wrote:
>
> Hello,
>
> On Wed, 27 May 2015 12:54:04 +0200 Xavier Serrano wrote:
>
> > Hello,
> >
> > Slow requests, blocked requests and blocked ops occur quite often
> > in our cluster; too often
en medium) clusters, so you'll have to
> research the archives and net (the CERN Ceph slide is nice).
> One thing I remember is "kernel.pid_max", which is something you're likely
> to run into at some point with your dense storage nodes:
> http://ceph.com/docs/master/sta
their own bucket (permissions are set
to read and write, not public).
With this set of permissions, the user can delete its own bucket and
create another one with a different name. We'd like to avoid this.
It this possible?
Thank you very much for your help.
Best regards,
- Xavier Serrano
-
