Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DEE4068.9090802@dude.podzone.net>
Date: Tue, 07 Jun 2011 09:14:48 -0600
From: AJ <aj@dude.podzone.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Re: Backups, Snapshots, SSTable Data Files, Compaction
References: <4DEDB132.4070100@dude.podzone.net>	<4DEDB65C.203@datastax.com>
	<4DEDD135.6090800@dude.podzone.net>
 <BANLkTi=-Zks61ghf1WOZ5qUnhS5PT+UESA@mail.gmail.com>
In-Reply-To: <BANLkTi=-Zks61ghf1WOZ5qUnhS5PT+UESA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/7/2011 2:29 AM, Maki Watanabe wrote:
> You can find useful information in:
> http://www.datastax.com/docs/0.8/operations/scheduled_tasks
>
> sstables are immutable. Once it written to disk, it won't be updated.
> When you take snapshot, the tool makes hard links to sstable files.
> After certain time, you will have some times of memtable flushs, so
> your sstable files will be merged, and obsolete sstable files will be
> removed. But snapshot set will remains on your disk, for backup.
>

Thanks for the doc source.  I will be experimenting with 0.8.0 since it 
has many features I've been waiting for.

But, still, if the snapshots don't link to all of the previous sets of 
.db files, then those unlinked previous file sets MUST be safe to 
manually delete.  But, they aren't deleted until later after a GC.  It's 
a bit confusing why they are kept after compaction up until GC when they 
seem to not be needed.  We have Big Data plans... one node can have 10's 
of TBs, so I'm trying to get an idea of how much disk space will be 
required and whether or not I can free-up some disk space.

Hopefully someone can still elaborate on this.