Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of rrabah@playdom.com designates
 74.125.149.205 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <e06563880912031809k3149b86fj659c7d10a1f3339b@mail.gmail.com>
References: <a1625f290912031518i79552f45td31f7c9a797007b9@mail.gmail.com>
	 <a1625f290912031807p4a75fbe5i3fc36d41f7711d60@mail.gmail.com>
	 <e06563880912031809k3149b86fj659c7d10a1f3339b@mail.gmail.com>
Date: Fri, 4 Dec 2009 10:51:40 -0800
Message-ID: <a1625f290912041051m60e382adl7e44aa71663372c2@mail.gmail.com>
Subject: Re: Removes increasing disk space usage in Cassandra?
From: Ramzi Rabah <rrabah@playdom.com>
To: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think there might be a bug in the deletion logic. I removed all the
data on the cluster by running remove on every single key I entered,
and I run major compaction
nodeprobe -host hostname compact on a certain node, and after the
compaction is over, I am left with one data file/ one index file and
the bloom filter file,
and they are the same size of data as before I started doing the deletes.

On Thu, Dec 3, 2009 at 6:09 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> cassandra never modifies data in-place. =A0so it writes tombstones to
> supress the older writes, and when compaction occurs the data and
> tombstones get GC'd (after the period specified in your config file).
>
> On Thu, Dec 3, 2009 at 8:07 PM, Ramzi Rabah <rrabah@playdom.com> wrote:
>> Looking at jconsole I see a high number of writes when I do removes,
>> so I am guessing these are tombstones being written? If that's the
>> case, is the data being removed and replaced by tombstones? and will
>> they all be deleted eventually when compaction runs?
>>
>>
>>
>> On Thu, Dec 3, 2009 at 3:18 PM, Ramzi Rabah <rrabah@playdom.com> wrote:
>>> Hi all,
>>>
>>> I ran a test where I inserted about 1.2 Gigabytes worth of data into
>>> each node of a 4 node cluster.
>>> I ran a script that first calls a get on each column inserted followed
>>> by a remove. Since I was basically removing every entry
>>> I inserted before, I expected that the disk space occupied by the
>>> nodes will go down and eventually become 0. The disk space
>>> actually goes up when I do the bulk removes to about 1.8 gigs per
>>> node. Am I missing something here?
>>>
>>> Thanks a lot for your help
>>> Ray
>>>
>>
>