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