CEPH filesystem development
 help / color / mirror / Atom feed
From: Alphe Salas Michels <asalas@kepler.cl>
To: ceph-devel <ceph-devel@vger.kernel.org>
Subject: rbd after removal still 10 TB used.
Date: Mon, 09 Jun 2014 20:46:34 -0400	[thread overview]
Message-ID: <5396556A.8010908@kepler.cl> (raw)

Hello,
I have this issue to submit you.It is with ceph emperor version 0.72 i 
don t know if in firefly it is solved. I didnt see in the changelog any 
change to that issue.

First of all ceph is storage ogre. Let me explain. In an global 40TB 
disk the real data i can use is 40 TB /2 - 25% = around 15TB. But as I 
delete data and store new data I notice the replicas are never 
overwritten. logically a pg has its mirror and so if the pg is updated 
then the mirrored pg corresponding is updated too. or better said if a 
pg is overwritten with new data then its related pg mirror is 
overwritten too with that new data. Experience in real life shown to me 
that it is not the case. Simply pg are overwriten and a new pg mirror is 
created to contain the new data letting the old pg mirror remain. So as 
i delete and overwrite  data to my rbd image I notice the ever growing 
effect that lead to a forever pgs stuck to backfill osds. So slowly ceph 
is stopping to accept new data. More osd are in near_full ratio then 
full ratio.

Still after I do a rbd rm myimagename I notice that because some pgs 
where stuck to backfill then i still have 10 TB locked. Only way to 
retrieve that data is to completly clear the ceph cluster and reinstall 
a new version. I don t think most people using ceph will affort an ever 
growing ceph system, because yes beleive it or not new disks and new 
nodes have a cost, and that it is not  wise to have replicas that over 
match more than 3 times the data they backup on a replica = 2 environement.


At the time ceph is willing to extend it seems we are all oblivious to 
the core problems of ceph. No data triming no data replicas triming.

Probably triming data is ressource consuming. So we should have at least 
a "lets plan and do a trim for that day" possibility. The other way 
around would be to have a better replica management since that is where 
the problem is orginated.

Best regards

-------
Alphe Salas

                 reply	other threads:[~2014-06-10  0:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=5396556A.8010908@kepler.cl \
    --to=asalas@kepler.cl \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox