[
https://issues.apache.org/jira/browse/CASSANDRA-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725733#comment-14725733
]
Joshua McKenzie commented on CASSANDRA-10222:
---------------------------------------------
Added a 3.0 branch link and updated the 2.2 w/new branch name.
Fixed the ctor and logger name.
bq. Perhaps we could schedule only the failed snapshot deletions where the
snapshot parent directory is the same as the sstable directory?
While we certainly could, I'm not convinced the extra complexity and folder
structure dependence of the comparison/mapping between directories is justified
by the delta in functionality. This got me to thinking - I've updated the 2.2
and 3.0 branch to have a call to {{SnapshotDeletingTask.rescheduleFailedTasks}}
at the tail end of {{CompactionExecutor.afterExecute}}. That combined with the
calls that percolate through GCInspector should keep us with a pretty tight
window between the absolute earliest a snapshot could be deleted on windows and
when it actually occurs with a minimal amount of added complexity.
> 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)
