[ 
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)

Reply via email to