Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 2 Sep 2015 02:24:45 +0000 (UTC)
From: "Stefania (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12860295.1440775474000.230313.1441160685855@Atlassian.JIRA>
In-Reply-To: <JIRA.12860295.1440775474000@Atlassian.JIRA>
References: <JIRA.12860295.1440775474000@Atlassian.JIRA>
 <JIRA.12860295.1440775474090@arcas>
Subject: [jira] [Commented] (CASSANDRA-10222) Periodically attempt to delete
 failed snapshot deletions on Windows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726616#comment-14726616 ] 

Stefania commented on CASSANDRA-10222:
--------------------------------------

Looks much better now. Just one comment:

* When we catch the exception in {{Directories.clearSnapshot()}} did you mean to retry immediately by calling {{run()}}? I think not because the constructor will also submit the task. 

It was a nice idea to add the call to {{CompactionExecutor.afterExecute}}, all compaction operations go though this executor right?

I noticed you haven't run CI yet. I suppose it makes more sense to run it on Windows than on Linux?

> Periodically attempt to delete failed snapshot deletions on Windows
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-10222
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10222
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Joshua McKenzie
>            Assignee: Joshua McKenzie
>              Labels: Windows
>             Fix For: 2.2.2
>
>
> The changes in CASSANDRA-9658 leave us in a position where a node on Windows will have to be restarted to clear out snapshots that cannot be deleted at request time due to sstables still being mapped, thus preventing deletions of hard links. A simple periodic task to categorize failed snapshot deletions and retry them would help prevent node disk utilization from growing unbounded by snapshots as compaction will eventually make these snapshot files deletable.
> Given that hard links to files in NTFS don't take up any extra space on disk so long as the original file still exists, the only limitation for users from this approach will be the inability to 'move' a snapshot file to another drive share. They will be copyable, however, so it's a minor platform difference.
> This goes directly against the goals of CASSANDRA-8271 and will likely be built on top of that code. Until such time as we get buffered performance in-line with memory-mapped, this is an interim necessity for production roll-outs.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)